Decoding of unsupported ARC codes (Lighting4)

[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]

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.

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.

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.

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.

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?

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]

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}

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

[ext23]

Hi Willi,

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

BR
Daniel

[Willi]

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

[ext23]

But I still have it on my wishlist ;-)

It wasn't my intention to push yourself ;-)

How 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

[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;

But 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

[Willi]

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

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

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

[Willi]

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

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

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

[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}

[Willi]

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}

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?

[Willi]

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.

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?

[Willi]

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

[Willi]

Du hast eine PM mit einer Testversion.

Ich habe die Testversion noch so geändert, dass bei Set über die Weboberfläche die Auswahl richtig gesetzt wird. Ich schreibe gerade die Doku für commandref und habe vor die Nutzung noch im WIKI anhand von Beispielen zu dokumentieren.

Wenn noch jemand anders testen will, einfach eine PM an mich.  
Sobald ich Feedback darüber habe, dass es funktioniert, kommt es ins SVN.

[Willi]

Ich habe die Testversion noch so geändert, dass bei Set über die Weboberfläche die Auswahl richtig gesetzt wird. Ich schreibe gerade die Doku für commandref und habe vor die Nutzung noch im WIKI anhand von Beispielen zu dokumentieren.

Ich habe die Nutzung im WIKI unter http://www.fhemwiki.de/wiki/RFXtrx#PT2262_empfangen_und_senden_mit_TRX_LIGHT.pm beschrieben.

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

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?

The WD18 transmits a keep alive code with battery and alarm status.
I did not have time to test your PR2262 code but I hope to do it soon. Thanks for your work

[Willi]

Ich habe soeben das Senden von PT2262 sowie Koppla im SVN eingecheckt. Koppla ist noch nicht dokumentiert (Syntax siehe vorheriges Posting). Es gibt noch etwas Debugging-Output im Log.

[ext23]

Hallo Willi,

Schön wäre, wenn Du vergleichen könntest, ob der bei hexline von mir generierte Code dem entspricht, der auch von RFXmngr geschrieben wird.

Habe ich soeben gemacht und konnte bei meinen Stichproben keine Unterschiede feststellen bis auf die Sequenz Nummer die du immer auf 0x00 lässt, aber das ist ja OK so.

Also bis jetzt funktioniert das alles wunderbar.

Mir ist nur eins aufgefallen, aber das hat jetzt nichts mit dir und deinem Modul zu tun. Ich hab hier zwei exakt baugleiche Fernbedienungen, beide mit demselben Code und beide lassen die Steckdose schalten, aber nur eine von den beiden wird vom RFXTRX433 erkannt. Da muss ich nochmal meinen Logik Analysator ran klemmen. Ich vermute mal, dass die eine Fernbedienung im Timing zu stark abweicht von dem standard und der RFXTRX433 diesen dann nicht erkennt.

Achso, hier mal die Typen (Fürs Protokoll :-) ):
- H+H FSD 42 433,92MHz --> Die arbeitet wunderbar mit RFXTRX433, davon habe ich mehrere
- Unitec EIM-821/Art.48110 --> Die Signale erkennt RFXTRX433 nicht bzw. nur sporadisch


Gruß Daniel

Und nochmals vielen Dank für die Arbeit die du in das Modul steckst und gesteckt hast!

[Willi]

Hallo Willi,
Habe ich soeben gemacht und konnte bei meinen Stichproben keine Unterschiede feststellen bis auf die Sequenz Nummer die du immer auf 0x00 lässt, aber das ist ja OK so.

Hallo Daniel,

danke für die Info.
Ja, die Sequenznumer setze ich immer auf 0x00. Ich habe mir die Arbeit gespart hier eine globale Squenznummer für TRX einzuführen. Das ist gemäß RFXCOM in Ordnung so. So richtig kann ich den Sinn der Sequenznummer (noch) nicht erkennen.......

Mir ist nur eins aufgefallen, aber das hat jetzt nichts mit dir und deinem Modul zu tun. Ich hab hier zwei exakt baugleiche Fernbedienungen, beide mit demselben Code und beide lassen die Steckdose schalten, aber nur eine von den beiden wird vom RFXTRX433 erkannt. Da muss ich nochmal meinen Logik Analysator ran klemmen. Ich vermute mal, dass die eine Fernbedienung im Timing zu stark abweicht von dem standard und der RFXTRX433 diesen dann nicht erkennt.

Achso, hier mal die Typen (Fürs Protokoll :-) ):
- H+H FSD 42 433,92MHz --> Die arbeitet wunderbar mit RFXTRX433, davon habe ich mehrere
- Unitec EIM-821/Art.48110 --> Die Signale erkennt RFXTRX433 nicht bzw. nur sporadisch

Wäre gut, wenn Du Deine Ergebnisse nach der Analyse an RFXCOM geben könntest. Evtl. macht es ja Sinn das Timing beim Empfang von PT2262 noch etwas anzupassen.

Und nochmals vielen Dank für die Arbeit die du in das Modul steckst und gesteckt hast!

Danke für Deine Tests!

[HarryT]

Hi willi

I updated today and tried to set a PT2262 device (a pir sensor) and get:

error set name=PIR1 deviceid=330100101000 (needs to be base4 and has 12 digits)

I volunteerd for testing before and volunteer again when a bugfix is available.

{HT}

[HarryT]

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}

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.

I have these http://www.ebay.com/itm/110944135469?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649

I am pretty sure all the stuff for this "Home security system" (433 Mhz) will work as I guess they all use the SC2262 chip to communicate. On http://stores.ebay.com/HOURSE-SAFE?_trksid=p2047675.l2563  you can see lots of this stuff.

No I don't get a commission of this seller. :-) I guess a lot of other chinese sellers sell stuff which will also work, but I found none of them who could tell me which chipset is used. So until the first part is tested, you are not sure.

{HT}

[ext23]

Wäre gut, wenn Du Deine Ergebnisse nach der Analyse an RFXCOM geben könntest. Evtl. macht es ja Sinn das Timing beim Empfang von PT2262 noch etwas anzupassen.

Tja sehr komisch die Werte sehen gut aus, sind etwas unter 350µs pro Takt und 128 haben wir ja ... passt mit den 41ms also, und das ist bei beiden gleich, dennoch verstehe ich nicht wieso die eine nicht funktioniert, bzw. nur dann wenn ich diese 10 cm an den RFXTRX433 hänge. Aber kann ja auch sein, dass im HF Teil etwas nicht passt, das kann ich aber nicht mehr messen ;-) Aber gut ist auch egal, hat für mich kein Mehrwert da dies die einzige FB ist die nicht geht, von dem her, war eben nur die Neugierde woran es hätte liegen können ;-)

Das ist die FB die funktioniert:
(siehe Anhang / see attachement)

Und diese geht eben nur eingeschränkt:
(siehe Anhang / see attachement)

Wie man sieht haut das alles hin. Aber gut das ist jetzt hier auch ein bissel Off Topic, aber vielleicht interessiert sich ja irgend wann mal einer dafür.

Gruß Daniel

[Willi]

Hi willi

I updated today and tried to set a PT2262 device (a pir sensor) and get:

error set name=PIR1 deviceid=330100101000 (needs to be base4 and has 12 digits)

I volunteerd for testing before and volunteer again when a bugfix is available.

{HT}

Hello Harry,

I have written some more information on http://www.fhemwiki.de/wiki/RFXtrx#PT2262_empfangen_und_senden_mit_TRX_LIGHT.pm .

My understanding was that PT2262 just supports Tristate values 0,1,2 but not 3.
See also http://www.princeton.com.tw/Portals/0/Product/PT2262_5.pdf .

But I may be wrong.

Just change line 344 of 46_TRX_LIGHT.pm from
        if (uc($pt2262_cmd) =~ /^[0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2]$/ ) {
to
        if (uc($pt2262_cmd) =~ /^[0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3]$/ ) {

and try again.

Regards

Willi

[Willi]

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}

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.

I have these http://www.ebay.com/itm/110944135469?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649
{HT}

Do they work with the existing PT2262 receive of RFXtrx433?
Do you have an example how they are defined in FHEM?

[HarryT]

Do they work with the existing PT2262 receive of RFXtrx433?
Do you have an example how they are defined in FHEM?

Yes and after the update of yesterday, even my watchdog seems to work as expected.

In xml:
<TRX_LIGHT name="PIR1" state="Beweging" sets="Stil Beweging off on  " attrs="room group comment alias eventMap userReadings IODev ignore:1,0 do_not_notify:1,0 loglevel:0,1,2,3,4,5,6 event-on-change-reading event-on-update-reading event-min-interval stateFormat devStateIcon icon invertState onOffDevice sortby toggleDevice webCmd">
         <INT key="DEF" value="PT2262 13030010100 light 0:off,1:on"/>
         <INT key="NAME" value="PIR1"/>
         <INT key="NR" value="167"/>
         <INT key="STATE" value="Beweging"/>
         <INT key="TRX_LIGHT_commandcodes" value="0:off,1:on"/>
         <INT key="TRX_LIGHT_deviceid" value="13030010100"/>
         <INT key="TRX_LIGHT_devicelog" value="light"/>
         <INT key="TRX_LIGHT_type" value="PT2262"/>
         <INT key="TYPE" value="TRX_LIGHT"/>
         <INT key="IODev" value="TRX_0"/>
         <ATTR key="eventMap" value="off:Stil on:Beweging"/>
         <ATTR key="room" value="Aanwezig"/>
         <STATE key="light" value="on" measured="2013-04-05 19:52:22"/>
         <STATE key="state" value="on" measured="2013-04-05 19:52:22"/>
      </TRX_LIGHT>

In fhem.cfg
define PIR1 TRX_LIGHT PT2262 13030010100 light 0:off,1:on

This is the information you need?

{HT}

[HarryT]

.

My understanding was that PT2262 just supports Tristate values 0,1,2 but not 3.
See also http://www.princeton.com.tw/Portals/0/Product/PT2262_5.pdf .

But I may be wrong.

Just change line 344 of 46_TRX_LIGHT.pm from
        if (uc($pt2262_cmd) =~ /^[0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2][0-2]$/ ) {
to
        if (uc($pt2262_cmd) =~ /^[0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3][0-3]$/ ) {

and try again.

Regards

Willi

The setting works now. And I get 3 lines in my logging for every set. I will send them in a PM. Just a bit strange, in the web interface I see now 1 or zero and not the light bulb on or off.

Did you change the wiki today? I didn't see changes so quickly.

{HT}

[Willi]

The setting works now. And I get 3 lines in my logging for every set. I will send them in a PM. Just a bit strange, in the web interface I see now 1 or zero and not the light bulb on or off.

Did you change the wiki today? I didn't see changes so quickly.

{HT}

Good to know. I have now changed this in the SVN to "0-3" instead "0-2" for the check. Should be avaliable via update tomorrow.

The threee lines logging for the set are just for debugging until I know that everything works.

For the web interface: How did you do the set exactly? Doing the set with 1 or with on?
I am not sure how the webinterface does this. Maybe we need the state to set on or off?

Could you do a list DEVICENAME after the set?

Regards

Willi

[Willi]

The setting works now. And I get 3 lines in my logging for every set. I will send them in a PM. Just a bit strange, in the web interface I see now 1 or zero and not the light bulb on or off.

Did you change the wiki today? I didn't see changes so quickly.

{HT}

Good to know. I have now changed this in the SVN to "0-3" instead "0-2" for the check. Should be avaliable via update tomorrow.

The three lines logging for the set are just for debugging until I know that everything works.

For the web interface: How did you do the set exactly? Doing the set with 1 or with on?
I am not sure how the webinterface does this. Maybe we need the state to set on or off?

Could you do a list DEVICENAME after the set?
A few exapmpe outputs would be nice.

Regards

Willi

[HarryT]

For the web interface: How did you do the set exactly? Doing the set with 1 or with on?

I tried all the 4 ways available in the web interface.

I am not sure how the webinterface does this. Maybe we need the state to set on or off?

Could you do a list DEVICENAME after the set?
A few exapmpe outputs would be nice.

Regards

Willi

list PIR1 before setting:

Internals:
   DEF        PT2262 13030010100 light 0:off,1:on
   IODev      TRX_0
   LASTInputDev TRX_0
   MSGCNT     1
   NAME       PIR1
   NR         169
   STATE      Beweging
   TRIGGERTIME 2013-04-05 21:02:21
   TRX_0_MSGCNT 1
   TRX_0_RAWMSG 09130000710441015e60
   TRX_0_TIME 2013-04-05 21:02:21
   TRX_LIGHT_commandcodes 0:off,1:on
   TRX_LIGHT_deviceid 13030010100
   TRX_LIGHT_devicelog light
   TRX_LIGHT_type PT2262
   TYPE       TRX_LIGHT
   Readings:
     2013-04-05 21:02:21   light           on
     2013-04-05 21:02:21   state           on
Attributes:
   eventMap   off:Stil on:Beweging
   room       Aanwezig


list PIR1 after the setting:

Internals:
   DEF        PT2262 13030010100 light 0:off,1:on
   IODev      TRX_0
   LASTInputDev TRX_0
   MSGCNT     1
   NAME       PIR1
   NR         169
   STATE      1
   TRIGGERTIME 2013-04-05 21:05:11
   TRX_0_MSGCNT 1
   TRX_0_RAWMSG 09130000710441015e60
   TRX_0_TIME 2013-04-05 21:02:21
   TRX_LIGHT_commandcodes 0:off,1:on
   TRX_LIGHT_deviceid 13030010100
   TRX_LIGHT_devicelog light
   TRX_LIGHT_type PT2262
   TYPE       TRX_LIGHT
   Readings:
     2013-04-05 21:02:21   light           on
     2013-04-05 21:05:11   state           1
Attributes:
   eventMap   off:Stil on:Beweging
   room       Aanwezig

The difference is "state".

Can I help more?

{HT}

[Willi]

Could you try to change the lines 384 from
"
  $hash->{CHANGED}[0] = $command;
  $hash->{STATE} = $command;
  $hash->{READINGS}{state}{TIME} = $tn;
  $hash->{READINGS}{state}{VAL} = $command;
"

to

"
  $hash->{CHANGED}[0] = $a[1];
  $hash->{STATE} = $a[1];
  $hash->{READINGS}{state}{TIME} = $tn;
  $hash->{READINGS}{state}{VAL} = $a[1];
"

and try a "set PIR1 on"

The state should be "on" after this and the webinterface should look better?

-- Willi

[ext23]

My understanding was that PT2262 just supports Tristate values 0,1,2 but not 3.

--> That's right, PT2262/HX2262 can only handle TreState.

I got also this values sometimes (normally if I release a Button of my PT2262 RC...)

2013-04-03_23:04:22 TRX_PT2262 010101111133
2013-04-03_23:04:23 TRX_PT2262 hex: 11155f
2013-04-03_23:04:23 TRX_PT2262 bin: 000100010001010101011111
2013-04-03_23:04:23 TRX_PT2262 codes: up middle up middle up middle middle middle middle middle down down

But eveything is ok as we have only "three states":
00 = 0 = up = GND
01 = 1 = middle = float
11 = 3 = down = VCC
10 = 2 = not allowed/not used

BR
Daniel

[HarryT]

That is just perfect.

Thanks.

{HT}

[Willi]

That is just perfect.

Thanks.

{HT}

Ok. Fixes for the state are now in SVN and should be in update tomorrow.

Also I have reduced the number of lines logged for each set. There is now just a single line for each set in the log. We may remove this later.

-- Willi

[HarryT]

[quote title=HarryT schrieb am Fr, 05 April 2013 15:45]

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}

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.

Surprise! I got my new Chinees PIR sensors today. They looked 100% identical and are bought from the same supplier. But they have another print and have a smaller SC2262 chip inside. The lucky news is they work too with your PT2262 solution.

I now have MW-HW3 and XY-HW8 sensors according to the print.

BTW when using: you need to select 3,3 Mhz (be careful to buy a device which supports 3,3 Mhz). Further leave the 9e place of the settings open and remove the 9e digit from the sequence reported by the PT2262 module. That should be enough to get it to work. At least for me.  

[Willi]

Surprise! I got my new Chinees PIR sensors today. They looked 100% identical and are bought from the same supplier. But they have another print and have a smaller SC2262 chip inside. The lucky news is they work too with your PT2262 solution.
 

Very good news. Do you have a pointer (URL) to the items you bought? Or is it the same URL you have already posted?

-- Willi

[HarryT]

Very good news. Do you have a pointer (URL) to the items you bought? Or is it the same URL you have already posted?

-- Willi

Yes it is the same URL.

{HT}

[HarryT]

Further leave the 9e place of the settings open and remove the 9e digit from the sequence reported by the PT2262 module.  
 

:-( for my latest PIR sensors it is position 12. So you have to play with the last 4 jumpers to find the correct one which have to be left out. I found position 9 and 12 as the correct place for my types of sensors.

{HT}

[Willi]

Further leave the 9e place of the settings open and remove the 9e digit from the sequence reported by the PT2262 module.  
 

:-( for my latest PIR sensors it is position 12. So you have to play with the last 4 jumpers to find the correct one which have to be left out. I found position 9 and 12 as the correct place for my types of sensors.

{HT}

How do the sensors work? Is there any Keepalive signal (signal when there is no movement) or just a signal when PIR reports alarm. How many packets are send when alarm is reported?

I would be very interested to see parts of a log of one of the PIR sensors.

[HarryT]

How do the sensors work? Is there any Keepalive signal (signal when there is no movement) or just a signal when PIR reports alarm. How many packets are send when alarm is reported?

I would be very interested to see parts of a log of one of the PIR sensors.

[/quote]

They just detect movement. There is no keepalive I arrange this with a watchdog definition.

How can I found out the number of packets send? Just with the rfxmngr?

A small part of a logfile:
2013-04-01_01:01:27 PIR1 light: Beweging
2013-04-01_01:01:27 PIR1 Beweging
2013-04-01_01:01:48 PIR1 light: Beweging
2013-04-01_01:01:48 PIR1 Beweging
2013-04-01_09:26:32 PIR1 light: Beweging
2013-04-01_09:26:32 PIR1 Beweging
2013-04-01_09:37:41 PIR1 light: Beweging
2013-04-01_09:37:41 PIR1 Beweging
2013-04-01_09:38:40 PIR1 light: Beweging
2013-04-01_09:38:40 PIR1 Beweging
2013-04-01_09:38:53 PIR1 light: Beweging
2013-04-01_09:38:53 PIR1 Beweging
2013-04-01_09:39:12 PIR1 light: Beweging
2013-04-01_09:39:12 PIR1 Beweging
2013-04-01_09:39:24 PIR1 light: Beweging
2013-04-01_09:39:24 PIR1 Beweging
2013-04-01_09:39:36 PIR1 light: Beweging
2013-04-01_09:39:36 PIR1 Beweging
2013-04-01_09:39:49 PIR1 light: Beweging
2013-04-01_09:39:49 PIR1 Beweging
2013-04-01_09:40:52 PIR1 light: Beweging
2013-04-01_09:40:52 PIR1 Beweging

{HT}

[Willi]

How do the sensors work? Is there any Keepalive signal (signal when there is no movement) or just a signal when PIR reports alarm. How many packets are send when alarm is reported?

I would be very interested to see parts of a log of one of the PIR sensors.

They just detect movement. There is no keepalive I arrange this with a watchdog definition.

How can I found out the number of packets send? Just with the rfxmngr?
{HT}[/quote]

Thanks for the information.

Yes, the only simple way would be using RFXmngr.

On my FHEM drivers I do discard multiple packets if they occur within 2 seconds. Thus you will not see multiple packets. I do this because many Oregon sensors and also X10 send multiple packets. I would be bad if you will see them as separate notify on FHEM.

-- Willi

[HarryT]

How can I found out the number of packets send? Just with the rfxmngr?
{HT}

Thanks for the information.

Yes, the only simple way would be using RFXmngr.

-- Willi

They only send 1 packet for a movement.

{HT}

[Willi]

The WD18 transmits a keep alive code with battery and alarm status.

I have ordered two WD18 and have installed one of these today.

The WD18 shows up as a X10 security remote (KR18).

When I press the test button, I get messages telling me alert and also battery status ok.
After this the device seem not to send directly a normal status.

After 1 hour I got the normal status and the battery status was low.

How does it work for you?

-- Willi

[oliv06]

The WD18 transmits a keep alive code with battery and alarm status.

I have ordered two WD18 and have installed one of these today.

The WD18 shows up as a X10 security remote (KR18).

When I press the test button, I get messages telling me alert and also battery status ok.
After this the device seem not to send directly a normal status.

After 1 hour I got the normal status and the battery status was low.

How does it work for you?

-- Willi

I have to check this evening. By the way battery status has always been low with my battery. I did not change it yet, and WD18 beeps regularly to complain...

[Willi]

Bert from RFXCOM gave me the answer.

I have to set the switch to S instead to R of the WD18. Now it shows up as a DS10A dor switch and everything works as expected. On Alarm it shows Opened and after alarm is show closed.

-- Willi

[oliv06]

Bert from RFXCOM gave me the answer.

I have to set the switch to S instead to R of the WD18. Now it shows up as a DS10A dor switch and everything works as expected. On Alarm it shows Opened and after alarm is show closed.

-- Willi

Thank you. I changed the switch to S.

[Willi]

Thank you. I changed the switch to S.

I have found out that battery works now ok, but some other things (like tamper) works different.

I am currently testing a new dev_type WD18 which should give the correct results.
I will let you know when I put it into SVN. The new define for it will look like:

Code Auswählen Erweitern

define TRX_Wassermelder1 TRX_SECURITY WD18 16fc water