From 7f24599c6a69771d6d0728e2aaf463bec0fbb02b Mon Sep 17 00:00:00 2001 From: borisneubert Date: Sun, 2 Nov 2008 18:04:33 +0000 Subject: [PATCH] - feature: new modules 00_CM11.pm and 20_X10.pm for integration of X10 devices in fhem - feature: X10 support for pgm3 git-svn-id: https://svn.fhem.de/fhem/trunk@261 2b470e98-0d58-463d-a4d8-8e2adae1ed80 --- fhem/CHANGED | 4 + fhem/HISTORY | 5 + fhem/contrib/dblog/93_DbLog.pm | 39 +- fhem/docs/X10/README | 4 + fhem/docs/X10/protocol.txt | 1024 +++++++++++++++++++++++++++++++ fhem/docs/commandref.html | 213 +++++-- fhem/docs/fhem.html | 33 +- fhem/webfrontend/pgm3/index.php | 4 +- 8 files changed, 1255 insertions(+), 71 deletions(-) create mode 100644 fhem/docs/X10/README create mode 100644 fhem/docs/X10/protocol.txt diff --git a/fhem/CHANGED b/fhem/CHANGED index 3c5d970e2..4fe149e04 100644 --- a/fhem/CHANGED +++ b/fhem/CHANGED @@ -435,3 +435,7 @@ - feature: The strange stty settings in 00_FHEM.pm are optional - bugfix: webpgm2 iPhone fix - feature: fullinit and reopen commands for FHZ added (Boris 2008-11-01) + - bugfix: avoid access to undefined NotifyFn in hash in fhem.pl (Boris 2008-11-01) + - feature: new modules 00_CM11.pm and 20_X10.pm for integration of X10 + devices in fhem (Boris 2008-11-02) + - feature: X10 support for pgm3 (Boris 2008-11-02) diff --git a/fhem/HISTORY b/fhem/HISTORY index 90a0a9e09..b4466a7d9 100644 --- a/fhem/HISTORY +++ b/fhem/HISTORY @@ -316,4 +316,9 @@ Fri Jul 25 18:14:26 MEST 2008 - Boris Sat Nov 01 CET 2008 - feature: new commands fullinit and reopen for FHZ, commandref.html update + - bugfix: avoid access to undefined NotifyFn in hash in fhem.pl +- Boris Sun Nov 02 CET 2008 + - feature: new modules 00_CM11.pm and 20_X10.pm for integration of X10 + devices in fhem + - feature: X10 support for pgm3 \ No newline at end of file diff --git a/fhem/contrib/dblog/93_DbLog.pm b/fhem/contrib/dblog/93_DbLog.pm index ba14683b6..0f43727b4 100755 --- a/fhem/contrib/dblog/93_DbLog.pm +++ b/fhem/contrib/dblog/93_DbLog.pm @@ -34,7 +34,7 @@ DbLog_Define($@) my ($hash, $def) = @_; my @a = split("[ \t][ \t]*", $def); - return "wrong syntax: define DbLog configuration regexp" + return "wrong syntax: define DbLog configuration regexp" if(int(@a) != 4); my $regexp = $a[3]; @@ -58,7 +58,7 @@ DbLog_Undef($$) { my ($hash, $name) = @_; my $dbh= $hash->{DBH}; - $dbh->disconnect() if(defined($dbh)); + $dbh->disconnect() if(defined($dbh)); return undef; } @@ -101,17 +101,18 @@ DbLog_ParseEvent($$) # EMEM, M232Counter, M232Voltage return plain numbers - if(($type eq "M232Voltage") || + if(($type eq "M232Voltage") || ($type eq "M232Counter") || ($type eq "EMEM")) { } # FS20 - elsif($type eq "FS20") { + elsif(($type eq "FS20") || + ($type eq "X10")) { @parts= split(/ /,$value); my $reading= $parts[0]; if(!defined($reading)) { $reading= ""; } if($#parts>=1) { $value= join(" ", shift @parts); - if($reading =~ m(^dim*%$)) { + if($reading =~ m(^dim*%$)) { $value= substr($reading,3,length($reading)-4); $reading= "dim"; $unit= "%"; @@ -121,7 +122,7 @@ DbLog_ParseEvent($$) } } } - # FHT + # FHT elsif($type eq "FHT") { if($reading =~ m(-from[12]\ ) || $reading =~ m(-to[12]\ )) { @parts= split(/ /,$event); @@ -131,7 +132,7 @@ DbLog_ParseEvent($$) } if($reading =~ m(-temp)) { $value=~ s/ \(Celsius\)//; $unit= "°C"; } if($reading =~ m(temp-offset)) { $value=~ s/ \(Celsius\)//; $unit= "°C"; } - if($reading =~ m(^actuator[0-9]*)) { + if($reading =~ m(^actuator[0-9]*)) { if($value eq "lime-protection") { $reading= "actuator-lime-protection"; undef $value; @@ -165,7 +166,7 @@ DbLog_ParseEvent($$) undef $value; } else { - $value=~ s/%//; $value= $value*1.; $unit= "%"; + $value=~ s/%//; $value= $value*1.; $unit= "%"; } } } @@ -179,8 +180,8 @@ DbLog_ParseEvent($$) if($reading eq "rain") { $value=~ s/ \(l\/m2\)//; $unit= "l/m2"; } if($reading eq "rain_raw") { $value=~ s/ \(counter\)//; $unit= ""; } if($reading eq "humidity") { $value=~ s/ \(\%\)//; $unit= "%"; } - if($reading eq "israining") { - $value=~ s/ \(yes\/no\)//; + if($reading eq "israining") { + $value=~ s/ \(yes\/no\)//; $value=~ s/no/0/; $value=~ s/yes/1/; } @@ -190,13 +191,13 @@ DbLog_ParseEvent($$) if($event =~ m(T:.*)) { $reading= "data"; $value= $event; } if($reading eq "temperature") { $value=~ s/ \(Celsius\)//; $unit= "°C"; } if($reading eq "humidity") { $value=~ s/ \(\%\)//; $unit= "%"; } - if($reading eq "battery") { + if($reading eq "battery") { $value=~ s/ok/1/; $value=~ s/replaced/1/; $value=~ s/empty/0/; } } - + @result= ($reading,$value,$unit); return @result; @@ -209,7 +210,7 @@ DbLog_Log($$) { # Log is my entry, Dev is the entry of the changed device my ($log, $dev) = @_; - + # name and type required for parsing my $n= $dev->{NAME}; my $t= $dev->{TYPE}; @@ -232,10 +233,10 @@ DbLog_Log($$) my $reading= $r[0]; my $value= $r[1]; my $unit= $r[2]; - if(!defined $reading) { $reading= ""; } - if(!defined $value) { $value= ""; } - if(!defined $unit) { $unit= ""; } - + if(!defined $reading) { $reading= ""; } + if(!defined $value) { $value= ""; } + if(!defined $unit) { $unit= ""; } + my $is= "(TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES " . "('$ts', '$n', '$t', '$s', '$reading', '$value', '$unit')"; @@ -287,7 +288,7 @@ sub DbLog_ExecSQL1($$) { my ($dbh,$sql)= @_; - + my $sth = $dbh->do($sql); if(!$sth) { Log 2, "DBLog error: " . $DBI::errstr; @@ -300,7 +301,7 @@ sub DbLog_ExecSQL($$) { my ($hash,$sql)= @_; - + Log 5, "Executing $sql"; my $dbh= $hash->{DBH}; if(!DbLog_ExecSQL1($dbh,$sql)) { diff --git a/fhem/docs/X10/README b/fhem/docs/X10/README new file mode 100644 index 000000000..3478464fd --- /dev/null +++ b/fhem/docs/X10/README @@ -0,0 +1,4 @@ +protocol.txt is taken from the source tar ball of the programm heyu from +Daniel B. Suthers. + + diff --git a/fhem/docs/X10/protocol.txt b/fhem/docs/X10/protocol.txt new file mode 100644 index 000000000..f3601053d --- /dev/null +++ b/fhem/docs/X10/protocol.txt @@ -0,0 +1,1024 @@ + Interface Communication Protocol + Version DBS 1.8 + +Originally taken from the X10 web page Dec 25, 1996. +Some mistakes corrected. DBS Jan 1, 1997 +Updated Jan 24 to match the Jan 6th version of X10's doc. The main +difference was the cable pin-out. +Updated Feb 13, 2000 to add info about the HAIL command. +Updated Aug 24, 2001 by Charles W. Sullivan (cwsulliv@triad.rr.com) +to include identification of CM11a timer bits for Security mode, +clarification of "All xxx" command macro element format and termination +of macro initiator table. +Updated Sep 1, 2002 by Charles W. Sullivan to clarify operation of +the battery timer and correct the definitions of bits 0-3 in the +section 8 "Set Interface Clock" block. +Updated May 19, 2003 by Charles W. Sullivan to correct the format +for extended code commands (per Buzz Burrowes), clarify the format +of extended code macro elements and add a note regarding suppression +of address byte transmission in macro elements. +Updated Nov 4, 2003 by Charles W. Sullivan to add note regarding +the effect of having the same time for the start and stop event +in a timer. +Updated Mar 7,2004 by Charles Sullivan to add note regarding +usage of bits 12-14 in the macro initiator. + + +1. X-10 Transmission Coding (overview). + +1.1 Housecodes and Device Codes. + +The housecodes and device codes range from A to P and 1 to 16 +respectively although they do not follow a binary sequence. The encoding +format for these codes is as follows + + Housecode Device Code Binary Value Hex Value + A 1 0110 6 + B 2 1110 E + C 3 0010 2 + D 4 1010 A + E 5 0001 1 + F 6 1001 9 + G 7 0101 5 + H 8 1101 D + I 9 0111 7 + J 10 1111 F + K 11 0011 3 + L 12 1011 B + M 13 0000 0 + N 14 1000 8 + O 15 0100 4 + P 16 1100 C + +1.2 Function Codes. + + Function Binary Value Hex Value + All Units Off 0000 0 + All Lights On 0001 1 + On 0010 2 + Off 0011 3 + Dim 0100 4 + Bright 0101 5 + All Lights Off 0110 6 + Extended Code 0111 7 + Hail Request 1000 8 + Hail Acknowledge 1001 9 + Pre-set Dim (1) 1010 A + Pre-set Dim (2) 1011 B + Extended Data Transfer 1100 C + Status On 1101 D + Status Off 1110 E + Status Request 1111 F + + NOTE: The only devices that I own that respond to the status request + command are the RR501 RF receivers. If anyone knows of others I'd like + to hear about them. + + +2. Serial Parameters. + +The serial parameters for communications between the interface and PC +are as follows: + + Baud Rate: 4,800bps + Parity: None + Data Bits: 8 + Stop Bits: 1 + +2.1 Cable connections: + + Signal DB9 Connector RJ11 Connector + SIN Pin 2 Pin 1 + SOUT Pin 3 Pin 3 + GND Pin 5 Pin 4 + RI Pin 9 Pin 2 + +where: SIN Serial input to PC (output from the interface) + SOUT Serial output from PC (input to the interface) + GND Signal ground + RI Ring signal (input to PC) + + +3. X-10 Transmission. + +3.1. Standard Transmission. + +An X-10 transmission from the PC to the interface typically refers to +the communication of a Housecode and Device Code combination or the +transmission of a function code. The format of these transmissions is: + + PC Interface +2 bytes Header:Code +1 byte checksum +1 byte Acknowledge +1 byte interface ready to receive + +This format is typical of all transmissions between the PC and the +interface with the difference being in the first transmission from the +PC. + +3.1.1. Header:Code. + +The Header:Code combination is configured thus: + + Bit: 7 6 5 4 3 2 1 0 + Header: < Dim amount > 1 F/A E/S + +Where: + +Dim amount (dims) is a value between 0 and 22 identifying the number of dims to +be transmitted (22 is equivalent to 100%) + +Bit 2 is always set to '1' to ensure that the interface is able to +maintain synchronization. + +F/A defines whether the following byte is a function (1) or address (0). + +E/S defines whether the following byte is an extended transmission (1) +or a standard transmission (0). + + + Bit: 7 6 5 4 3 2 1 0 + Address: < Housecode > + Function:< Housecode > < Function > + +Note the function only operates for devices addressed with the same Housecode. + +3.1.2. Interface Checksum and PC Acknowledge + +When the interface receives a transmission from the PC, it will sum all +of the bytes, and then return a byte checksum. If the checksum is +correct, the PC should return a value of 0x00 to indicate that the +transmission should take place. If however, the checksum is incorrect, +then the PC should again attempt to transmit the Header:Code combination +and await a new checksum. + +3.1.3. Interface Ready to Receive. + +Once the X-10 transmission has taken place (and this may be quite time +consuming in the case of Dim or Bright commands) the interface will send +0x55 to the PC to indicate that it is in a 'ready' state. + +3.1.4. Example. + + PC Interface Description + 0x04,0x66 Address A1 + 0x6a Checksum ((0x04 + 0x66)&0xff) + 0x00 OK for transmission. + 0x55 Interface ready. + + 0x04,0x6e Address A2 + 0x72 Checksum ((0x04 + 0x6e)&0xff) + 0x00 OK for transmission. + 0x55 Interface ready. + + 0x86,0x64 Function: A Dim 16/22*100% + 0xe0 Incorrect checksum. + 0x86,0x64 Function re-transmission + 0xea Checksum ((0x86 + 0x64)&0xff) + 0x00 OK for transmission. + 0x55 Interface ready. + +This transmission will address lamp modules A1 and A2, and then dim them +by 72%. Note multiple addresses cannot be made across housecodes, i.e. +A1, B2 Dim 72% is not valid, and would result in B2 being dimmed by +72%. + +3.2. Extended X-10 Transmission. + +Extended X-10 transmission is simply an extension of the protocol to +allow two additional bytes of extended data to be transmitted. In this +case, the protocol may be shown as: + + PC Interface +5 bytes Header:Function:Unitcode:Data:Command +1 byte checksum +1 byte Acknowledge +1 byte interface ready to receive + +(Corrected by CWS per input from Buzz Burrowes. The original specified +only 4 bytes.) + +The header for an extended transmission is always: + + Bits: 7 6 5 4 3 2 1 0 + Header: 0 0 0 0 0 1 1 1 + +Bits 7 to 3 are always zero because the dim level is not applicable to +extended transmissions. +Bit 2 must be set to '1' as in all PC header transmissions. +Bit 1 is set to '1' as the extended transmission is always a function. +Bit 0 is set to '1' to define an extended transmission rather than a +standard transmission. + +The function byte is: + + Bits: 7 6 5 4 3 2 1 0 + Function: < Housecode > 0 1 1 1 + +Again, the housecode must be the same as any previously addressed +modules, and for extended data, the function code must be 0111. + +The unitcode byte contains the encoded unit in the lower nybble. + +Finally, the data and command bytes may take any value between 0x00 and 0xff. +Note that the checksum is one byte and is defined as: + + checksum = (header + function + unitcode + data + command)&0xff + +4. X-10 Reception. + +Whenever the interface begins to receive data from the power-line, it +will immediately assert the serial ring (RI) signal to initiate the +wake-up procedure for the PC. Once the data reception is complete, the +interface will begin to poll the PC to upload its data buffer (maximum +10 bytes). If the PC does not respond, then the interface's data buffer +will overrun, and additional data will not be stored within the buffer. + +4.1. Interface Poll Signal. + +In order to poll the PC, the interface will continually send: + + bits: 7 6 5 4 3 2 1 0 + Poll: 0 1 0 1 1 0 1 0 (0x5a) + +This signal will be repeated once every second until the PC responds. + +4.2. PC Response to the Poll Signal. + +To terminate the interface's polling and initiate the data transfer, the +PC must send an acknowledgment to the interface's poll signal. This +acknowledgment is: + + bits: 7 6 5 4 3 2 1 0 + Ack : 1 1 0 0 0 0 1 1 (0xc3) + +Notice that bit #2 of the PC transmission is not set, indicating that +this cannot be the beginning of a transmission from the PC. + + +4.3. Interface Serial Data Buffer. + +The buffer consists of 10 bytes defined as follows: + + Byte Function + 0 Upload Buffer Size + 1 Function / Address Mask + 2 Data Byte #0 + 3 Data Byte #1 + 4 Data Byte #2 + 5 Data Byte #3 + 6 Data Byte #4 + 7 Data Byte #5 + 8 Data Byte #6 + 9 Data Byte #7 + +The interface will only upload the specified number of bytes within +the buffer, and will not default to uploading 10 bytes in every +transmission. The number of bytes to receive is thus specified in byte +0 of the transmission. The counting of the number of bytes starts at +the mask (shown as byte 1). + + +The function address mask indicates whether the following 8 bytes +should be interpreted as an address or as a function. The position of +the bit in the mask corresponds to the Data byte index within the data +buffer. If the bit is set (1), the data byte is defined as a function, +and if reset (0), the byte is an address. Bit 0 coresponds to Data Byte 0. + +The data bytes are in the same format as for the Code byte in the X-10 +transmissions (i.e. Housecode:Device Code or Housecode:Function). + +Note that once the data buffer has been uploaded, there is no +acknowledgment from the PC to the interface as the contents of the +serial data buffer will have been changed. This will not cause a problem +as this is simply informing the PC of the external status, rather than +controlling a device (as in the case of the PC transmission) which may +have safety implications. + +4.4. Dim or Bright. + +After a dim or bright code, the PC will expect the following byte to be +the change in brightness level. An X-10 module has 210 discrete +brightness levels, and therefore this byte will be equivalent to a +brightness change of n/210*100%. + +4.5. Extended Code. + +Extended code is processed in a similar way to Dim and Bright, except +that the PC will expect two bytes, which are the Data and Command +bytes. + + +4.6. Example. + + PC Interface Description + 0x5a Poll from interface. + 0xc3 'PC Ready' Response from PC + 0x06 6 byte transmission + 0x04 xxxx x100-> byte 0,1 addresses, + 2 function + 0xe9 B6 + 0xe5 B7 + 0xe5 B Bright + 0x58 0x58/210 * 100% + +This transmission will wake the computer, and then indicate that a +transmission of length 5 bytes will occur, data bytes 0 and 1 are +addresses and byte 2 is a bright function, which means that the +following byte is the change in brightness level. + +5. Fast Macro Download. + +The interface contains a 42 byte buffer which contains macro codes. +These macro codes are initiated upon the reception of a pre-defined +address (i.e. B7), and the code specifies the transmissions that the +interface should then make. Due to the shortage of bytes, the macro code +is 'compressed' by grouping similar functions. + +Note, any error in the function codes may result in the interface +entering an endless loop and becoming 'locked-up', so steps should be +taken to ensure that the code is correct prior to transmission. + +If the interface detects that it has suffered a power-down situation, it +will ring the PC and poll with a specialized code to indicate that the +macros must be refreshed. + +5.1. Power-fail Macro Download Poll Code. + NOTE: I beleive that this is mainly for the CP10. The battery + backed CM11 does send this poll after a power failure, but it + responds to a setclock directive rather than the macro download. + It waits till the resumption of power before it starts sending this byte. + DBS, Jan 1, 1997 + +In order to poll the PC, the interface will continually send: + + Poll: 7 6 5 4 3 2 1 0 + Value: 1 0 1 0 0 1 0 1 (0xa5) + +This signal will be repeated once every second until the PC responds with +a clock update ( 0x9b see section 8). + +5.2. PC Response to Macro Download Poll Code. + +To stop the polling, the PC must respond with: + + PC Response: 7 6 5 4 3 2 1 0 + Value : 1 1 1 1 1 0 1 1 (0xfb) + +Once this has been transmitted, the macro must be immediately +downloaded. At this stage, the interface will wait until the 42 byte +macro has been received before any X-10 transmissions can occur. + + +5.3. Macro Code (CM10). + +Macro code is divided into individual macros, and functional groups +within the macros. The only limit to the number of macros and groups is +the number of available storage bytes. + +Each macro begins with an initiator byte which details the Housecode and +Device code that will cause the macro to start. + +Following the initiator byte is the length of this current macro, and +the functional trigger (ie On or Off functions). The length is defined +by the lower 7 bits, and the functional trigger by the most significant +bit. If the most significant bit is set, the functional trigger is 'On', +and if reset, the functional trigger is 'Off'. + +As mentioned previously, the macro is divided into functional groups, +and each group has a byte indicating the length of the group before the +macro is defined. This group length byte is exclusive of the function +code. + +The group is then made up of a common housecode (1 nibble), followed by +a number of device codes (each takes 1 nibble) and finally a function +code (1 nibble). If the function code falls on a byte boundary, then it +is always the low nibble of the byte. + +All unused bytes must take a value of 0x00. + +5.3.1. Dimming and Brightening within a macro. + +If the function is a bright or dim, then the next byte specifies the +change in brightness level in 22 steps. Note if the most significant bit +of this byte is set, the interface will send out enough bright commands +to ensure that the associated lamps are at 100%, and then dim the lamp +by the specified value. + +5.3.2. Extended codes in macros. + +Extended code cannot be grouped as for other functions, and consequently +an extended code group would be defined as: + + Byte Description + 0x01 Group length + 0xa7 Housecode D (1010 = D), Extended code function + 0x03 Device code 11 (0011 = 11) + 0xff Data byte: 0xff + 0x55 Command byte: 0x55 + +5.3.3. Checksum. + +Once the macro has been downloaded, the interface calculates the 1 byte +checksum by summing all 42 bytes of the macro code (not including the PC +macro download start byte) and returns the appropriate value. If the +value is incorrect, the PC should again initiate the macro download by +transmitting the PC macro download start byte. + + +5.3.4. Example. + + PC Interface Description + 0xa5 Power-fail, macro poll. + 0xfb Macro download start byte + + 0x26 Initiator C1 + 0x0a Functional Trigger: 'Off'; + Macro length: 10 bytes + 0x04 Group length: 4 nibbles + 0x66 Macro housecode, A, device 1 + 0x2e Devices 2 and 3 + 0x04 Dim + 0x0b Dim by 11/22*100% = 50% + 0x02 group length: 2 nibbles + 0x6a Macro housecode, A, device 4 + 0x02 Function: On + + 0x26 Initiator C1 + 0x8c Functional Trigger: 'On'; + Macro length: 12 bytes + 0x02 Group length: 2 nibbles + 0x66 Macro housecode, A, device 1 + 0x02 Function: On + 0x03 Group length: 3 nibbles + 0x6e Macro housecode, A, device 2 + 0x42 Device 3, Function Dim (0100) + 0x06 Dim by 6/22*100% = 27% + 0x02 Group length: 2 nibbles + 0x6a Macro housecode, A, device 4 + 0x03 Function: Off + + 0x00... Remaining 20 bytes set to 0x00 + 0x91 Macro checksum: 0x91 + 0x00 Checksum correct + 0x55 Interface ready + +5.4. EEPROM Code (CM11 and CP10). + +The EEPROM code for the CM11 and CP10 contains both the downloaded +timers and also the macro data. The timers are resolved into 'pseudo- +macros' with the only difference being in the initiator (ie a timer as +opposed to a macro code). + +In other words, a timer points to a macro. The timer initiator table is +checked every minute to see if any of the entrys should trigger +a macro. Macro initiators, on the other hand, are checked anytime an +X10 signal is detected over the power lines. + +The EEPROM may be broken down into four categories: + + Macro Offset (two bytes) + Timer Initiators (continues until an 0xff byte) + Macro Initiators (continues to start of macro offset) + Macro Data. + +5.4.1. Macro Offset. + +The first two bytes of the EEPROM contain an offset to the macro +initiator table. The macro initiator table is offset rather than the +timers as the timers must be processed every minute, whereas the macros +are only processed whenever an X-10 transmission event is detected. + +5.4.2. Timer Initiator. + +The timers reside in a table beginning at address 0x0002 in the EEPROM. +The table is terminated by a 0xff at the end of the table. Each 9-byte +timer entry contains the following data: + +Bit range Description +71 Reserved +70 to 64 Day of the week mask (bit 1 = Sunday, bit 7 = Saturday) +63 to 56 Start day range (day of the year) bits 0 to 7) +55 to 48 Stop day range (bits 0 to 7) +47 to 44 Event start time x 120 minutes +43 to 40 Event stop time x 120 minutes +39 Start day range (bit 8) +38 to 32 Event start time (0 to 120 minutes, bits 0 to 6) +31 Stop day range (bit 8) +30 to 24 Event stop time (0 to 120 minutes, bits 0 to 6) +23 Start event security mode. +22 Reserved +21 to 20 Start event macro pointer (bits 8 to 9) +19 Stop event security mode. +18 Reserved +17 to 16 Stop event macro pointer (bits 8 to 9) +15 to 8 Start event macro pointer (bits 0 to 7) +7 to 0 Stop event macro pointer (bits 0 to 7) + +The day of the week and day of the year are ANDed, so both have to match the +current time before the event will trigger a macro. + +The event macro pointer has the address of the macro that will be executed +when this event is triggered. + +If the security mode bit is set, the CM11a will add a time varying from +0 to 60 minutes to the event time. + +Note: If the times for the start and stop events in a given timer are +the same, then only the start event will occur and the stop event +will be ignored. + +5.4.3. Macro Initiator. + +The macro initiators are configured thus: + +Bit range Description +23 to 20 Initiator house code +19 to 16 Initiator device code +15 Initiator function ('1' = on, '0' = off) +14 to 12 Reserved (See Section 7.) +11 to 0 Macro pointer (bits 0 to 11) + +The table of macro initiators is terminated with two bytes of 0xff. + +5.4.4. Macro data. + +Macro data starts with a timer offset in minutes (0 for instant to 240 +for 4 hours) relative to the timer value. Following the timer offset +is the number of elements within the macro (1 to 255). This is +followed by the macro elements themselves: + + +Packet = delay:number_elements:macro_element(data) + +The macro elements are configured as follows: + + +Basic command: + +Bit range Description +23 to 20 Command house code +19 to 16 Command function +15 to 0 X10 format device bitmap + +Bright or dim commands: + +Bit range Description +31 to 28 Command house code +27 to 24 Command function +23 to 8 X10 format device bitmap +7 Brighten first ('1') or simply dim ('0') +6 to 5 Reserved +4 to 0 Dim value (ranging from 0 to 22) + +Extended data commands: + +Bit range Description +47 to 44 Command house code +43 to 40 Command function +39 to 24 X10 format device bitmap +23 to 0 Extended code data + +The above should have been titled "Extended Code commands" instead of +"Extended data commands". The "Extended Data Transfer" command (0x0C) +is only a 3 byte Basic macro element (and as a macro element transfers +no data). Macro elements for Extended Code commands are programmed +thus: + +Bit range Description +47 to 44 Command house code +43 to 40 Command function (0x7) +39 to 24 X10 format device bitmap +23 to 16 Unit code (in lower nybble) +15 to 8 Data byte +7 to 0 Extended type|command function + +The Extended Code commands are understood by modules such as the +LM14A two-way lamp module. For a detailed description of the +extended type|command functions, see X10 document XTC798.DOC +which is available from their website. (CWS May 19, 2003) + +Setting the X10 format device bitmap to 0 will suppress transmission +of the Housecode|Unitcode address byte for those commands where this +byte is superfluous, e.g., the "All Lights On" command and (most) +Extended Code commands. (For whatever reason, Activehome sets the +bitmap to 0x0001, which corresponds to unit 13.) (CWS May 19, 2003). + +5.4.5. EEPROM Data Transfer. + +The EEPROM is downloaded to the interface in blocks of 19 bytes. The +first byte is the macro download initiator command byte (0xfb), followed +by two bytes containing the actual EEPROM address (this does not need to +be sequential, although it must not cross the 16 bit page boundary). 16 +bytes of EEPROM data follows the EEPROM address. + +Once the interface has received the EEPROM data, it will return a +checksum. If the checksum is correct, the PC will acknowledge (0x00) and +after the data has been programmed into the EEPROM, the interface will +return a 'ready' command (0x55) to indicate that it is available to +process PC requests. + +5.4.6. Example. + + PC Interface Description + + 0xfb EEPROM download start byte + (first block of data) + + 0x00 EEPROM address 0x0000 (lo byte) + 0x00 (hi byte) + + 0x00 EEPROM offset to macro initiators 0x000c + 0x0c (hi byte) + + 0x3e Day mask x 0111110 (.FTWTM.) + 0x00 Start day [0..7] + 0x6d Stop day [0..7] + 0x49 (Event start time, Event stop time) + x 120 minutes + 0x00 Start day range [8], + Event start time [0..6] + 0x80 Stop day range [8], + Event stop time [0..6] + 0x00 Start macro pointer [8..11], Stop + macro pointer [8..11] + 0x1d Start macro pointer [0..7] + 0x22 Stop macro pointer [0..7] + + Summary: Start day: 0x000 (Jan 1) + Stop day: 0x16d (Dec 31) + Start time: 4 x 120mins = 08:00 + Stop time: 9 x 120mins = 18:00 + Start macro pointer: 0x01d + Stop macro pointer: 0x022 + + 0xff Timer table delimiter + + 0x6a Macro initiator house and device + code (A4) + 0x80 Macro function (On) + 0x11 Macro pointer (0x011) + + 0xff + + 0xb8 Checksum from the interface + + 0x00 Checksum correct + + 0x55 Programming complete. Interface ready. + + 0xfb Second block of data + + 0x00 EEPROM start address (lo byte) + 0x10 EEPROM start address (hi byte) + + 0xff Macro table delimiter + + 0x00 Macro: instant + 0x01 1 element + 0x64 House code A, function Dim + 0x00 + 0x40 Bitmap: device #1 + 0x0b Dim level 11/22 = 50% + + 0x0f Macro: delayed by 15 minutes + 0x01 1 element + 0x64 House code A, function Dim + 0x00 + 0x40 Bitmap: device #1 + 0x80 Brighten to 100% + + 0x00 Macro: instant + 0x01 1 element + 0x62 House code A, function On + + 0x56 Checksum from the interface + + 0x00 Checksum correct + + 0x55 Programming complete + + 0xfb Third block of data + + 0x00 + 0x20 EEPROM start address + + 0x00 + 0x04 Bitmap: device #3 + + 0x00 Macro: instant + 0x01 1 element + 0x63 House code A, function Off + 0x00 + 0x04 Bitmap: device #3 + + 0x00 Zero pad for remainder + of the data stream + 0x00 + 0x00 + 0x00 + 0x00 + 0x00 + 0x00 + 0x00 + 0x00 + + 0x8c Checksum from the interface + 0x00 Checksum correct + + 0x55 Programming complete + + +6. Serial Ring Disable + +If may be required, for the sake of 'trouble-shooting' to disable the +serial ring (RI) signal, although undesirable as macros held within the +computer will not operate, nor will the computer be able to track the +system status. + +The following protocol will allow the serial ring (RI) signal to be +enabled and disabled: + +Enable Ring: + + PC Interface Description + 0xeb Enable the ring signal + 0xeb Checksum + 0x00 Checksum correct + 0x55 Interface ready + + +Disable Ring: + + PC Interface Description + 0xdb Disable the ring signal + 0xdb Checksum + 0x00 Checksum correct + 0x55 Interface ready + +The default state of the serial ring (RI) signal after a power on reset +is enabled. + +7. EEPROM Address (executed via timer or macro initiator). + +This command is purely intended for the CM11 and CP10. + +When the interface receives a fast macro initiator, or when a timer +event is processed, it will immediately perform an asynchronous +transmission of the EEPROM address that is subsequently processed. + +The command is of the form: + + 0x5b EEPROM address transmission + 0xhh High byte of macro EEPROM address (*) + 0xll Low byte of macro EEPROM address + +(*) Bit 7 of this byte is always 1. Bits 4-6 replicate the +"reserved" bits 12-14 (Section 5.4.3) when the transmission +results from a Macro Initiator or are 0 when from a Timer. +Only bits 0-1 are the high part of the EEPROM address. +(CWS Mar 7, 2004) + +This transmission is a one time transmission, and requires no +hand-shaking as the interface may not be connected to the PC. + +8. Set Interface Clock. + +This command is purely intended for the CM11 and CP10. + +The PC can set the interface clock with an unsolicited transmission at +any time. In addition, once the interface detects the absence of power, +it will request the current time from the PC when the PC is available as +follows: + +CM11: + +For a CM11, the time request from the interface is: 0xa5. + +The PC must then respond with the following transmission + + Note: The bit range is backwards from what you'd expect in serial + communications. Bit 55-48 is actually the first byte transmitted, + etc. To make matters worse, the bit orientation is correct within + the bit range, IE bits 4-7 of byte 6 _IS_ the monitored house code. + Further, bits 0 and 1 of byte 6 appear to be flipped. I get a + "monitor status clear" if bit 0 is set. + The original docs had bit 23 as part of current hours AND day. + DBS Jan 1, 1997 + + Descriptions of bits 0-3 are now correct as shown below. + CWS Sep 1, 2002 + +Bit range Description +55 to 48 timer download header (0x9b) (byte 0) +47 to 40 Current time (seconds) (byte 1) +39 to 32 Current time (minutes ranging from 0 to 119) (byte 2) +31 to 24 Current time (hours/2, ranging from 0 to 11) (byte 3) +23 to 15 Current year day (MSB is bit 15) (byte 4+.1) +14 to 8 Day mask (SMTWTFS) (byte 5-.1) +7 to 4 Monitored house code (byte 6...) +3 Reserved +2 Timer purge flag +1 Battery timer clear flag +0 Monitored status clear flag + +The CM11a will not respond to any other transmission until its time +request is satisfied. Per Buzz Burrowes, sending just the header (0x9b) +followed by some indeterminate delay of the order of 10 milliseconds +is sufficient to satisfy the time request without having to modify the +clock setting. (CWS May 19, 2003) + +CP10: + +For a CP10, the time request is from the interface is: 0xa6. + +The PC must then respond with the following transmission + Note: same as for the CM11. + +Bit range Description +63 to 56 Timer download header (0x7sb) +55 to 48 Current time (seconds) +47 to 40 Current time (minutes ranging from 0 to 119) +39 to 32 Current time (hours/2, ranging from 0 to 11) +31 to 23 Current year day +22 to 16 Day mask (SMTWTFS) +15 to 12 Monitored house code +11 Reserved +10 Battery timer clear flag +9 Monitored status clear flag +8 Timer purge flag +7 to 4 Power strip house code +3 to 0 Power strip device code + +9. Status Request. + +This command is purely intended for the CM11 and CP10. + +The PC can request the current status from the interface at any time as +follows: + +CM11: + +For a CM11, the status request is: 0x8b. + +The status request is immediately followed by: + + Note: This is really interesting. The btye order is reversed per + the note in section 8. The last 3 bytes are each mapped to show a + 1 in the bit position if the unit with value equating to the nibble + (section 1) is set. Low byte comes first, hi byte second. + Example: if unit 1 is on, the nibble = 6, so the mask + would show 00...0100000 + Note also that the hi bit of byte 6 must be multiplied by 256 and added to + the decimal value of byte 5 (+1) to find the Julian date. + DBS Jan 1, 1997 + + The battery timer "(set to 0xffff on reset)" below refers to a "cold" + restart, i.e, if the interface has been disconnected from AC power _and_ + the batteries have been removed for some indeterminate period of time. + When this condition occurs, it is necessary to send a status update with + the battery timer clear bit set, whereupon the timer will be reset + to 0000 and start to respond to interruptions in AC power, incrementing + by minutes of operation on battery power. + CWS Sep 1, 2002 + + +Bit range Description +111 to 96 Battery timer (set to 0xffff on reset) (Byte 0-1) +95 to 88 Current time (seconds) (Byte 2 ) +87 to 80 Current time (minutes ranging from 0 to 119) (Byte 3) +79 to 72 Current time (hours/2, ranging from 0 to 11) (Byte 4) +71 to 63 Current year day (MSB bit 63) (Byte 5+) +62 to 56 Day mask (SMTWTFS) (Byte 6-) +55 to 52 Monitored house code (Byte 7 lo) +51 to 48 Firmware revision level 0 to 15 (Byte 7 hi) +47 to 32 Currently addressed monitored devices (Byte 8-9) +31 to 16 On / Off status of the monitored devices (Byte 10-11) +15 to 0 Dim status of the monitored devices (Byte 12-13) + +CP10: + +For a CP10, the status request is: 0x6b. + +The status request is immediately followed by: + +Bit range Description +119 to 104 Battery timer (set to 0xffff on reset) +103 to 96 Current time (seconds) +95 to 88 Current time (minutes ranging from 0 to 119) +87 to 80 Current time (hours/2, ranging from 0 to 11) +79 to 71 Current year day +70 to 64 Day mask (SMTWTFS) +63 to 60 Monitored house code +59 to 56 Firmware revision level 0 to 15 +55 to 48 Power strip house and device code +47 to 32 Currently addressed monitored devices +31 to 16 On / Off status of the monitored devices +15 to 0 Dim status of the monitored devices + +10. Power-up Timer. + +This command is purely intended for the CP10. + +The interface contains a power-up timer that will turn on the remote +controlled sockets once it elapses on the assumption that the computer +has failed to boot-up. If it receives a message ('Relay Open' or 'Relay +Close', see item 7) from the computer before the timer elapses, then the +time-out is canceled and the sockets configured in accordance with the +message. + +The power-up timer is the fifth byte of the six byte transmission for +the scheduled ring, and it is split into two nibbles. The upper nibble +is a reload value and the lower nibble is the actual timer. Each timer +tick is 2 seconds, so the maximum timer value is 30 seconds. + +10.1. Transmission Protocol + +The PC can define the delay after which the power strip will turn the +controllable outlets on and off after detecting the PC turning on and +off. + +Bit range Description +55 to 48 Power-up timer download header (0xcb) +47 to 40 Reserved (0x00) +39 to 32 Reserved (0x00) +31 to 24 Reserved (0x00) +23 to 16 Reserved (0x00) +15 to 12 Power-up time-out (multiples of 2 seconds, range = 0 to 30s) +11 to 8 Reserved (0x0) +7 to 4 Power-down time-out (multiples of 2 seconds, range = 0 to 30s) +3 to 0 Reserved (0x0) + +The interface will respond with a checksum excluding the header. If +correct the PC should respond with 0x00, or download the correct value +again. The interface will terminate the transfer with 0x55 indicating +that it is ready to communicate with the PC. + +11. Relay Control. + +This command is purely intended for the CP10. + +The power-strip contains a relay that controls four extension sockets. +These sockets are controllable via the PC with the following commands: + +Close Relay (sockets on): + + PC Interface Description + 0xab Close the relay + 0xab Checksum + 0x00 Checksum correct + 0x55 Interface ready + +Open Relay (sockets off): + + PC Interface Description + 0xbb Open the relay + 0xbb Checksum + 0x00 Checksum correct + 0x55 Interface ready + +12. Input Filter Fail. + +This command is purely intended for the CP10. + +The power-strip contains an input filter and electrical surge protection +that is monitored by the microcontroller. If this protection should +become compromised (i.e. resulting from a lightening strike) the +interface will attempt to wake the computer with a 'filter-fail poll'. + +This poll signal takes the form: + + Poll: 7 6 5 4 3 2 1 0 + Value: 1 1 1 1 0 0 1 1 (0xf3) + +The poll signal will be repeated to the PC every second until the PC +responds with the default poll response: + + PC Response: 7 6 5 4 3 2 1 0 + Value: 1 1 1 1 0 0 1 1 (0xf3) + +13. Hail Commands (DBS) + +The Hail commands are set up so that you can detect other X10 controllers +that are on the same powerline as your controller and so that you can tell +the other controllers which house codes you are using. + +The hail protocol has two parts. First is the hail request (REQ) which +asks for other controllers to identify themselves. Second is the hail +acknowlege (ACK), which is sent by the other controllers in response to +the hail req. + +The CM11A does not automatically respond to the hail request. It must be done +by software. Activehome does this (or at one time did it - CWS) for the +Windows based systems. + +The ACK should contain the house code that you have active. If you have +several house codes, you could reply with all of them, one after the other. + +The transmisison for both ACK and REQ are one byte of function data in +the standard hc:function format. See section 4.3 for the serial data buffer +format. + +The REQ command appears to use any house code. The ACK should have the +house code set to the house code you are using. diff --git a/fhem/docs/commandref.html b/fhem/docs/commandref.html index ce2324000..8b3590835 100644 --- a/fhem/docs/commandref.html +++ b/fhem/docs/commandref.html @@ -49,11 +49,11 @@ You can use all of the following commands in in two ways: A minimal configuration file would look like: 
       attr global logfile /tmp/fhem.log
-      attr global statefile /tmp/fhem.save  
-      attr global verbose 3                   
-      attr global port 7072                   
+      attr global statefile /tmp/fhem.save
+      attr global verbose 3
+      attr global port 7072
       attr global modpath /usr/local/lib
-      define FHZ FHZ /dev/tts/USB0        
+      define FHZ FHZ /dev/tts/USB0
 
       define lamp FS20 8765 01
For other configuration files see the examples subdirectory.
@@ -1004,7 +1004,7 @@ fs20usr
- +

Type IPWE

    @@ -1013,21 +1013,21 @@ fs20usr Define a IPWE network attached weather data receiver device sold by ELV. Details see here. - It's intended to receive the same sensors as WS300 (8 T/H-Sensors and one kombi sensor), + It's intended to receive the same sensors as WS300 (8 T/H-Sensors and one kombi sensor), but can be accessed via http and telnet.
    For unknown reason, my try to use the telnet interface was not working neither with raw sockets nor with Net::Telnet module. Therefore i choosed here the "easy" way - to simple readout the http page and extract all data from the offered table. For this reason this module doesnt + to simple readout the http page and extract all data from the offered table. For this reason this module doesnt contain any option to configure this device.

    Note: You should give your sensors a name within the web interface, once they a received the first time.
    To extract a single sensor simply match for this name or sensor id

    - + Attributes:
    • delay: seconds between read accesses(default 300s)
      • - +

    Example: @@ -1039,7 +1039,70 @@ fs20usr

- + + +

Type CM11

+
    + define <name> CM11 <serial-device> +

    + CM11 is the X10 module to interface X10 devices with the PC.

    + + The current implementation can evaluate incoming data on the powerline of + any kind. It can send on, off, dimdown and dimup commands. +

    + This statement specifies the serial port to communicate with the CM11. + The name of the serial-device depends on your distribution. If serial-device + is none, then no device will be opened, so youcan experiment without + hardware attached.
    + + If you experience problems (for verbose 4 you get a lot of "Bad CRC message" + in the log), then try to define your device as
    + define <name> FHZ <serial-device> strangetty
    +
    + + Example: +
      + define x10if CM11 /dev/ttyUSB3
      +
    +
    +
+ + +

Type X10

+
    + define <name> X10 <model> <housecode> + <unitcode> +

    + + Defines an X10 device via its model, housecode and unitcode.

    + + Notes: +
      +
    • <model> is one of +
        +
      • lm12: lamp module, dimmable
        • +
      • lm15: lamp module, not dimmable
        • +
      • am12: appliance module, not dimmable
        • +
      • tm12: tranceiver module, not dimmable. Its + unitcode is 1.
        • +
      + Model determines whether a dim command is reasonable to be sent + or not.
      • +
    • <housecode> ranges from A to P.
      • +
    • <unitcode> ranges from 1 to 16.
      • +
    +
    + + Examples: +
      + define lamp1 X10 lm12 N 10
      + define pump X10 am12 B 7
      + define lamp2 X10 lm15 N 11
      +
    +
+
+ +

Type FileLog

    @@ -1078,23 +1141,23 @@ fs20usr
      define <name> DbLog <configfilename> <regexp>

      - + Log events to a database. The database connection is defined in - <configfilename> (see sample configuration file + <configfilename> (see sample configuration file db.conf). The configuration is stored in a separate file to avoid storing the password in the main configuration file and to have it visible in the output of the list command.

      - You must have 93_DbLog.pm in the FHEM subdirectory - to make this work. Additionally, the modules DBI and - DBD::<dbtype> need to be installed (use + You must have 93_DbLog.pm in the FHEM subdirectory + to make this work. Additionally, the modules DBI and + DBD::<dbtype> need to be installed (use cpan -i <module> if your distribution does not have it).

      <regexp> is the same as in FileLog.

      Sample code to create a MySQL database is in fhemdb_create.sql. - The database contains two tables: current and + The database contains two tables: current and history. The latter contains all events whereas the former only contains the last event for any given reading and device. The columns have the following meaning: @@ -1102,9 +1165,9 @@ fs20usr
    • TIMESTAMP: timestamp of event, e.g. 2007-12-30 21:45:22
    • DEVICE: device name, e.g. Wetterstation
    • TYPE: device type, e.g. KS300
      • -
    • EVENT: event specification as full string, +
    • EVENT: event specification as full string, e.g. humidity: 71 (%)
      • -
    • READING: name of reading extracted from event, +
    • READING: name of reading extracted from event, e.g. humidity
    • VALUE: actual reading extracted from event, e.g. 71
      • @@ -1114,8 +1177,8 @@ fs20usr yes is translated to 1.

      The current values can be retrieved by means of the perl script - fhemdb_get.pl. Its output is adapted to what a - Cacti data input method expects. + fhemdb_get.pl. Its output is adapted to what a + Cacti data input method expects. Call fhemdb_get.pl without parameters to see the usage information.

      @@ -1162,7 +1225,7 @@ fs20usr # Blink 3 times if the piri sends a command define n1 notify piri:on.* define a8 at +*{3}00:00:02 set lamp on-for-timer 1 - # Switch the lamp on from sunset to 11 PM + # Switch the lamp on from sunset to 11 PM # Copy 99_SUNRISE_EL.pm in the FHEM directory to have sunset_rel() { sunrise_coord("8.686", "50.112", "") } define a9 at +*{sunset_rel()} set lamp on @@ -1288,7 +1351,7 @@ fs20usr %EVENT (same as %), %NAME (same as @) and %TYPE (contains the device type, e.g. FHT) can be used. A single % - looses its special meaning if any of these parameters appears in the + looses its special meaning if any of these parameters appears in the definition.
    • <pattern> may also be a compound of @@ -1344,7 +1407,7 @@ fs20usr


      • Define a dummy. A dummy can take via set any values. - Used for programming. + Used for programming. Example:
        define myvar dummy
        @@ -1480,7 +1543,7 @@ fs20usr list statement for the device).

      - +

      Type WS2000:

        @@ -1495,8 +1558,8 @@ fs20usr RAW: original Data from interface

      - - + +

      Type IPWE

        @@ -1693,7 +1756,7 @@ Send buffer:
        2007-10-19 00:31:24 desired-temp 22.5
          modify <name> <type-dependent-options>

          - + Used to modify some definitions. Useful for changing some at or notify definitions. If specifying one argument to an at type deinition, only the time part will be changed. In @@ -1757,7 +1820,7 @@ Send buffer:
          2007-10-19 00:31:24 desired-temp 22.5
            save [<configfile>]

            - Save first the statefile, then the + Save first the statefile, then the configfile information. If a parameter is specified, it will be used instead the global configfile attribute.

            Notes: @@ -1792,7 +1855,9 @@ Send buffer:
            2007-10-19 00:31:24 desired-temp 22.5 time FHTcode activefor - raw + raw + initfull + reopen Notes:
            • use activefor if you have multiple FHZ devices, and you want to @@ -1810,6 +1875,26 @@ Send buffer:
              2007-10-19 00:31:24 desired-temp 22.5 central FHT code, which is used by the FHT devices. After changing it, you must reprogram each FHT80b with: PROG (until Sond appears), then select CEnt, Prog, Select nA.
              • +
            • If the FHT ceases to work for FHT devices whereas other devices + (e.g. HMS, KS300) continue to work, a
                + set FHZ initfull
              command could help. Try
                + set FHZ reopen
              if the FHZ + ceases to work completely. If all else fails, shutdown fhem, unplug + and replug the FHZ device. Problems with FHZ may also be related to + long USB cables or insufficient power on the USB - use a powered hub + to avoid such issues.
              • +
            • initfull issues the initialization sequence for the FHZ + device:
              + 
              +            get FHZ init2
+            get FHZ serial
+            set FHZ initHMS
+            set FHZ initFS20
+            set FHZ time
+            set FHZ raw 04 01010100010000
              • +
            • reopen closes and reopens the serial device port. This + implicitely initializes the FHZ and issues the + initfull command sequence.
          @@ -1830,7 +1915,7 @@ Send buffer:
          2007-10-19 00:31:24 desired-temp 22.5 off-for-timer on # dimmer: set to value before switching it off on-for-timer # see the note - on-old-for-timer # set to previous (before switching it on) + on-old-for-timer # set to previous (before switching it on) ramp-on-time # time to reach the desired dim value on dimmers ramp-off-time # time to reach the off state on dimmers reset @@ -1873,7 +1958,8 @@ Send buffer:
          2007-10-19 00:31:24 desired-temp 22.5 the program automatically schedules a "setstate off" for the specified time.
        • on-till requires an absolute time in the "at" format (HH:MM:SS, HH:MM - or {}, where the perl-code returns a time specification). + or { <perl code> }, where the perl-code returns a time + specification). If the current time is greater then the specified time, then the command is ignored, else an "on" command is generated, and for the given "till-time" an off command is scheduleld via the at command. @@ -1892,7 +1978,7 @@ Send buffer:
          2007-10-19 00:31:24 desired-temp 22.5 desired-temp day-temp night-temp report1 report2 - mode + mode holiday1 holiday2 # Not verified manu-temp # No clue what it does. year month day hour minute @@ -1941,7 +2027,7 @@ Send buffer:
          2007-10-19 00:31:24 desired-temp 22.5
        • pair
          The the FHT80b sent a "you-belong-to-me" to this actuator.
        - Note: + Note:

      @@ -2004,7 +2090,7 @@ Send buffer:
      2007-10-19 00:31:24 desired-temp 22.5
    • report2 with parameter 255 requests the following settings to be reported: day-temp night-temp windowopen-temp - lowtemp-offset desired-temp measured-temp mode warnings. + lowtemp-offset desired-temp measured-temp mode warnings. The argument is (more or less) a bitfield, to request unique values add up the following:
        @@ -2084,7 +2170,7 @@ Send buffer:
        2007-10-19 00:31:24 desired-temp 22.5

        Sets the state of all digital ports at once, value is 0..255.

        - set <name> [io0..io7] 0|1 + set <name> io0..io7 0|1

        Turns digital port 0..7 off or on.

        @@ -2099,6 +2185,57 @@ Send buffer:
        2007-10-19 00:31:24 desired-temp 22.5

      + +

      Type X10:

      +
        + set <name> <value> [<argument>] +

        + where value is one of:
        + 
        +    dimdown           # requires argument, see the note
+    dimup             # requires argument, see the note
+    off
+    on
+    on-till           # Special, see the note
+
        + Examples: +
          + set lamp1 dimup 10
          + set lamp1,lamp2 off
          + set pump off
          + set lamp2 on-till 19:59
          +
        +
        + Notes: +
          +
        • Only switching and dimming are supported by now.
          • +
        • Dimming is valid only for a dimmable device as specified by + the model argument in its define + statement. +
        • An X10 device has 210 discrete brightness levels. If you use a + X10 sender, e.g. a remote control or a wall switch to dim, a + brightness step is 100%/210.
          • +
        • dimdown and dimup take a number in the + range from 0 to 22 as argument. It is assumed that argument 1 is + a 1% brightness change (microdim) and arguments 2 to 22 are + 10%..100% brightness changes. The meaning of argument 0 is + unclear.
          • +
        • This currently leads to some confusion in the logs as the + dimdown and dimup codes are logged with + different meaning of the arguments depending on whether the commands + were sent from the PC or from a remote control or a wall switch.
          • +
        • dimdown and dimup from on and off states may + have unexpected results. This seems to be a feature of the X10 + devices.
          • +
        • on-till requires an absolute time in the "at" format + (HH:MM:SS, HH:MM) or { <perl code> }, where the perl code + returns a time specification). + If the current time is greater then the specified time, then the + command is ignored, else an "on" command is generated, and for the + given "till-time" an off command is scheduleld via the at command. +
          • +
        +

      Type FileLog:

        @@ -2214,12 +2351,12 @@ Send buffer:
        2007-10-19 00:31:24 desired-temp 22.5

        Device specification

          The commands - attr, + attr, deleteattr, delete, get, - list, - set, + list, + set, setstate, trigger can take a more complex device specification as argument, diff --git a/fhem/docs/fhem.html b/fhem/docs/fhem.html index 591bfcf43..490291c85 100644 --- a/fhem/docs/fhem.html +++ b/fhem/docs/fhem.html @@ -10,7 +10,7 @@

          FHEM

          -GPL'd server to access devices like FHZ1000/FHZ1300,EM1010PC,WS300,SCIVT. +GPL'd server to access devices like FHZ1000/FHZ1300,EM1010PC,WS300,SCIVT,X10. Formerly known as fhz1000.pl

          Current Version: (as of =DATE=) is webfrontends section for screenshots.

          Description

            This program makes the FHZ1000/FHZ1300/WS300 and other USB devices sold by ELV, -Conrad and others useable with Linux. In fact, there is nothing Linux special +Conrad and others as well as X10 devices sold by Marmitek, Powerhouse and +others useable with Linux. In fact, there is nothing Linux special in it, there are reports from OS X and Windows. You should be able to use it on other platforms as long as you can access the hardware as a serial device.
            The program runs as a server, you can control it via telnet, command line @@ -32,17 +33,25 @@ Currently implemented features:
            • Via the FHZ module (with access to one or more FHZ1000/FHZ1300 device):
                -
              • reading and sending FS20 events (on/off/dimming, timer commands)
                -
              • support of FS20 address features function group, local and global master +
              • reading and sending FS20 events (on/off/dimming, timer + commands)
                • +
              • support of FS20 address features function group, local and global + master
              • reading and changing FHT80b parameters (temp, actuator, etc).
                - The FHT8b seems to work too. Note: the FHT8 wont work.
                - Internal software buffer to prevent lost commands.
                -
                • + The FHT8b seems to work too. Note: the FHT8 wont work.
                + Internal software buffer to prevent lost commands.
              • reading HMS data (HMS100-T,-TF,-WD,-MG,-TFK,-CO,-FIT and RM100-2)
              • reading KS300 data
              - Note:The FHZ1350 WLAN is probably not working due to a prorietary - encryption. + Note: The FHZ1350 WLAN is probably not working due to a prorietary + encryption. +
              • +
            • Via the CM11 module (with access to a X10 computer interface): +
                +
              • reading all X10 events
                • +
              • sending X10 events (on/off/dimming)
                • +
              • on/off switching suppport
                • +
            • reading WS300 data, and up to 9 attached devices
            • reading EM1000WZ/EM1000EM/EM1000GZ data via an attached EM1010PC
              • @@ -130,7 +139,7 @@ and faq.html for more documentation.

              Server installation on Unix

              • Check the Makefile for the installation path, then type make install.
                • -
              • Create a configuration file (see the examples directory or +
              • Create a configuration file (see the examples directory or docs/commandref.html).
              • Start the server with fhem.pl <configfile>
              @@ -141,7 +150,7 @@ If you are using cygwin for your perl installation you can follow the guidelines
            • Be sure you have perl.exe in your path (%PATH%)
            • Make sure that you can access the serial USB device via virtual COM-Port or via socket(e.g. COMX or xport:10001).
              • -
            • Create a configuration file (see the examples directory and +
            • Create a configuration file (see the examples directory and docs/commandref.html)
            • Start the server with fhem.pl <configfile>
            @@ -179,7 +188,7 @@ If you are using cygwin for your perl installation you can follow the guidelines

            Web frontend 3 (webfrontend/pgm3)

              This frontend is PHP based and was contributed by Martin Haas. - Look at the webfrontends/pgm3/docs for more documentation or at + Look at the webfrontends/pgm3/docs for more documentation or at this screenshot. A lot more details can be found on Martins page: http://www.martin-haas.de/fhz diff --git a/fhem/webfrontend/pgm3/index.php b/fhem/webfrontend/pgm3/index.php index 77c6c7544..998bc0c98 100644 --- a/fhem/webfrontend/pgm3/index.php +++ b/fhem/webfrontend/pgm3/index.php @@ -334,7 +334,7 @@ xml_parser_free($xml_parser); if ($showroombuttons==1) for($i=0; $i < count($stack[0][children]); $i++) { - if (substr($stack[0][children][$i][name],0,5)=='FS20_') + if ( (substr($stack[0][children][$i][name],0,5)=='FS20_') || (substr($stack[0][children][$i][name],0,4)=='X10_')) { for($j=0; $j < count($stack[0][children][$i][children]); $j++) { @@ -599,7 +599,7 @@ xml_parser_free($xml_parser); for($i=0; $i < count($stack[0][children]); $i++) { ############################ - if (substr($stack[0][children][$i][name],0,5)=='FS20_') + if ((substr($stack[0][children][$i][name],0,5)=='FS20_')||(substr($stack[0][children][$i][name],0,4)=='X10_')) { $type=$stack[0][children][$i][name]; echo "";