Decoding of unsupported ARC codes (Lighting4)

Begonnen von oliv06, 05 Januar 2013, 00:00:41

Vorheriges Thema - Nächstes Thema

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:00I 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.

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.

ZitatHowever 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.

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.

ZitatDo 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?

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.
 
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

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}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Mi, 23 Januar 2013 14:04Hi 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}

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
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

ext23

Hi Willi,

btw. one question, how is your progress about the PT2262 "set" command?

BR
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Willi

Zitat von: ext23 schrieb am Do, 24 Januar 2013 13:41btw. one question, how is your progress about the PT2262 "set" command?
Hello Daniel,

due to other activities (childrens birthdays, home work, business trips, ...) I was not able to any coding for FHEM within the last weeks.

But I still have it on my wishlist ;-)

How is support for PT2262 receive working? Are you using it?

Regards

Willi
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

ext23

ZitatBut I still have it on my wishlist ;-)
It wasn't my intention to push yourself ;-)

ZitatHow is support for PT2262 receive working? Are you using it?
Yes of course, I have 3 PT2262 remote controls in use and your PT2262 support works fine for me!

BR
Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

ext23

Hi Willi, ich hoffe du hast alle Eier gefunden ;-)

Die "Nervensäge" wollte sich mal wieder melden, ich trau mich ja garnicht zu fragen;

ZitatBut I still have it on my wishlist ;-)

Wie ist denn der aktuelle Stand der Dinge?

Viele Grüße und noch schöne Oster Feiertage!

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Willi

Zitat von: ext23 schrieb am So, 31 März 2013 19:56Hi Willi, ich hoffe du hast alle Eier gefunden ;-)

Die "Nervensäge" wollte sich mal wieder melden, ich trau mich ja garnicht zu fragen;

ZitatBut I still have it on my wishlist ;-)

Wie ist denn der aktuelle Stand der Dinge?

Viele Grüße und noch schöne Oster Feiertage!

/Daniel

Du hast eine PM mit einer Testversion.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Willi

Zitat von: ext23 schrieb am So, 31 März 2013 19:56Hi Willi, ich hoffe du hast alle Eier gefunden ;-)

Die "Nervensäge" wollte sich mal wieder melden, ich trau mich ja garnicht zu fragen;

ZitatBut I still have it on my wishlist ;-)

Wie ist denn der aktuelle Stand der Dinge?

Viele Grüße und noch schöne Oster Feiertage!

/Daniel

Du hast eine PM mit einer Testversion.
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

HarryT

Willi/Daniel

Keep us informed it seems I have also problems with set on my cheap pir sensors.

BTW I guess the PT2622 thing should work for cheap smokedetectors (10 euro) too.

{HT}
FHEM 6.2 auf Raspberry Pi3  (1,2 Ghz)
RFXTRX433XL, ZWave, KFL200 and ConBeeIII
Raspberry Pi1 (0,7 Ghz) and Raspberry Pi4 for testing
German reading skills are good.

Willi

Zitat von: HarryT schrieb am Mo, 01 April 2013 22:37Keep us informed it seems I have also problems with set on my cheap pir sensors. BTW I guess the PT2622 thing should work for cheap smokedetectors (10 euro) too.
{HT}
I would be also very interested to know which devices work with the PT2262 code that would not work with other protocols supported by RFXtrx433.

@Daniel: Which devices do you use?
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Willi

Zitat von: oliv06 schrieb am Sa, 05 Januar 2013 00:00I 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.
Thanks for this link (Google translate helped me).

One question about the WD18. Does is transmit a keep alive code like X10-Security sensors like every one hour or so? Or do they just send an message when alarm is triggered.
The WD18 looks very interesting.

Have you tried to use the PR2262 code?
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433

Willi

Zitat von: ext23 schrieb am So, 31 März 2013 19:56Hi Willi, ich hoffe du hast alle Eier gefunden ;-)

Die "Nervensäge" wollte sich mal wieder melden, ich trau mich ja garnicht zu fragen;
Kein Problem, ich habe jetzt etwas Zeit bis Ende der Woche (=Urlaub). Wäre daher toll, wenn Du den Code kurzfristig testen könntest. Ich versuche mal heute oder morgen eine Doku dazu zu schreiben, damit ausser Dir jemand damit etwas anfangen kann......
FHEM@Q600(debian) mit DS9490R (1Wire) | FHEM@Sheevaplug(debian) mit RFXCOM-Receiver(80002), CULv3 & USB-WDE1 | FHEM@odroid mit CULv2 & RFXtrx433