FHEM - Hausautomations-Systeme > RFXTRX

Decoding of unsupported ARC codes (Lighting4)

(1/10) > >>

oliv06:
I use cheap and common GAO plugs sold on the french market. Hopefully they can be controlled by fhem because they understand "standard" ARC commands. I have written a short article in french in my blog (http://play.with.free.fr/index.php/domotique-avec-fhem-sur-dockstar/ on how to use them. But the protocol used by the remote is very specific and is not decoded. Bert (from RFXCOM) made some changes in the firmware (v60) but does not support these ARC decoding.

However for my own usage I have hacked the 46_TRX_LIGHT.pm module (in fhem 5.2 - I still have to look at the new code) in order to decode these commands so I can use the remote and have the status in FHEM. I must set the undec mode on the RFXtrx, and decode the specific codes generated by the remote.
Do you intend to have a standard way to do it in the main code, so I can adapt and propose my code to integrate in it? Or do you think it would imply too many specificities because of to many specific ARC variants?

Willi:

--- Zitat von: oliv06 schrieb am Sa, 05 Januar 2013 00:00 ---I use cheap and common GAO plugs sold on the french market. Hopefully they can be controlled by fhem because they understand "standard" ARC commands. I have written a short article in french in my blog (http://play.with.free.fr/index.php/domotique-avec-fhem-sur-dockstar/ on how to use them. But the protocol used by the remote is very specific and is not decoded. Bert (from RFXCOM) made some changes in the firmware (v60) but does not support these ARC decoding.

--- Ende Zitat ---


Hello oliv06,

I have written the FHEM support for RFXtrx433.
Unfortunately I do not speak french. I will try to understand your blog using google translate. Before doing this I will try to anwer your questions.


--- Zitat ---
However for my own usage I have hacked the 46_TRX_LIGHT.pm module (in fhem 5.2 - I still have to look at the new code) in order to decode these commands so I can use the remote and have the status in FHEM. I must set the undec mode on the RFXtrx, and decode the specific codes generated by the remote.

--- Ende Zitat ---


undec is no longer needed. On our request RFXCOM has implemented a new feature with Lighting4 that allows to receive raw PT2262 code. This is used when Lighting4 is switched on in RFXmngr.
Thanks a lot to Bert from RFXCOM for doing this!

I have already implemented support for Lighting4 which has a new feature since version 62 to receive raw PT2262 code. This new code was checked in SVN yesterday.


--- Zitat ---
Do you intend to have a standard way to do it in the main code, so I can adapt and propose my code to integrate in it? Or do you think it would imply too many specificities because of to many specific ARC variants?
--- Ende Zitat ---


Just update to the new FHEM code. Then update RFXtrx433 to version 62 or above. Set Lighting4 in RFXmngr and save this settings. This will also disable ARC as this new feature can not work together with ARC receive.

Running FHEM you will see that the PT2262 code will generate a new device TRX_PT2262 which will get the raw code. Please note that this FHEm driver support is still very experimental and currently not documented. I do currently test this new code with user ext23.

A description on how this works (before I will document this in commandref):

I have implemented the reception of the PT2262 code for users that know PT2262 codes. Users not knowning it should stay with the normal ARC code.

I've assumed that the PT2262 codes can be better read with Base 4 encoding. The RFXtrx433 firmware send 3 bytes on a reception of a PT2262 datagram. I do write this as 12 chars in base-4 code with the possible values ​​from 0-3.

For better understanding I will generate different encoding in the device TRX_PT2262. This device will be created by autocreate if it does not exist and write the following FileLog on a reception of a PR2262 datagram:

==> TRX_PT2262-2012.log <==
2012-12-30_21:39:17 TRX_PT2262 hex: 551515
2012-12-30_21:39:17 TRX_PT2262 bin: 010101010001010100010101
2012-12-30_21:39:17 TRX_PT2262 codes: middle middle middle middle up
middle middle middle up middle middle middle
2012-12-30_21:39:17 TRX_PT2262 111101110111

The state is in base 4 format as I think this is the relevant encoding.

The user will see on each keystroke of a remote control the different encoding in PT2262 format.

For example. A user presses buttons on the ELRO AB600 remote control on and off:

"pressed on:"
2012-12-30_21:40:42 TRX_PT2262 hex: 551515
2012-12-30_21:40:42 TRX_PT2262 bin: 010101010001010100010101
2012-12-30_21:40:42 TRX_PT2262 codes: middle middle middle middle up
middle middle middle up middle middle middle
2012-12-30_21:40:42 TRX_PT2262 111101110111

"pressed off:"
2012-12-30_21:40:47 TRX_PT2262 hex: 551514
2012-12-30_21:40:47 TRX_PT2262 bin: 010101010001010100010100
2012-12-30_21:40:47 TRX_PT2262 codes: middle middle middle middle up
middle middle middle up middle middle up
2012-12-30_21:40:47 TRX_PT2262 111101110110

The user will easily see that just the last digit changes when pressing on and off for the device. He will also see that 1 is on and 0 is off.

The user may now create a device on its own that reflect the code for this device.

For this he can specify the first x digits for the base 4 code a the device id. The last digits will be used for tha commands.

I assume that a PT2262 device will always use the first part of the digits for a deviceid and the last digits for commands. In the example above the device users 11 digits for the device id (11110111011) and one digit for the command.

The user may use the following define for TRX_LIGHT:

   define <name> TRX_LIGHT PT2262 <deviceid> <devicelog> <commandcodes>

The <deviceid> is specified in base 4 encoding. <commandcodes> specifies the possible base 4 digits for the command separated by : and a string that specifies a string that is the command.

Example:

define TRX_MYREMOTE1 TRX_LIGHT PT2262 11110111011 light 0:off,1:on

and the following FileLog:

define FileLog_TRX_MYREMOTE1 FileLog /var/log/fhem/TRX_MYREMOTE1-%Y.log
TRX_MYREMOTE1

As a result pressing the button on the remote control will generate the following events:

==> TRX_MYREMOTE1-2012.log <==
2012-12-30_21:54:56 TRX_MYREMOTE1 light: on
2012-12-30_21:54:56 TRX_MYREMOTE1 on

==> TRX_MYREMOTE1-2012.log <==
2012-12-30_21:54:59 TRX_MYREMOTE1 light: off
2012-12-30_21:54:59 TRX_MYREMOTE1 off

You will see that the result looks like a normal TRX_LIGHT device.

The name of <devicelog> (in this example light) and the command names (in the example on und off) can be chosen by the user on his need.

This implementation is surely not intended to be used for the normal user. It ist just intended to be used by users that know PT 2262 encoding and want to use a device that is not supported by normal ARC codes.

The next step will be to implement sending PR2262 codes.

Feel free to use this code if you want to and report the results back to me.
 

oliv06:
Hello Willi,
Thank you very much for your work and your explanations ! It seems to be exactly what I need. I will try it and let you know

HarryT:
Hi Willi

Would this give an opportunity to use the cheap PIR devices and door sensors sold on ebay? I can imagine that that may work.

{HT}

Willi:

--- Zitat von: HarryT schrieb am Mi, 23 Januar 2013 14:04 ---Hi Willi

Would this give an opportunity to use the cheap PIR devices and door sensors sold on ebay? I can imagine that that may work.

{HT}
--- Ende Zitat ---


Lighting4 receives RF signals code from PT2262 chipsets and compatible.
I guess that I could work if these devices use a PT2262 chipset or compatible coding. If they are using something else I am not sure. There are many many ways to code an RF signal on 433 Mhz.

Best Regards Willi

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln