PT2262(lighting4) - base4 vs. Tri(quad)-State

[KölnSolar]

Hi Oli,

ich hab mal wieder ne firmware-Aktualisierung(type2;1025) vorgenommen und auch lighting4 aktiviert.

Mir wurde dann brav ein PT2262-device angelegt, in dem ich in state die "raw" message(ohne device-type, msg-counter) base4-codiert erhielt. Es hat dann doch etwas gedauert, bis ich verstanden habe, was mir der Inhalt von state sagen soll.

Ist es nicht besser, wenn wir uns in FHEM an CUL/Intertechno-Sprech anlehnen ? Also von Tristate(Quadstate wurde dann "eingeführt", weil es devices(1527,pt2262) gibt, die auch die Bitfolge 10 haben) reden und auch entsprechend "visualisieren" und in der Definition benutzen.

In meinem Beispiel kommt vom TRX konkret raw: 0913005e368d08019560
also "reines" raw:            368d08             0195 60  (keine Ahnung, was die letzten 6 nibbles bedeutenAhh, 0195(=405[dec] ist der Basispuls)
im state umgesetzt          031220310020
als Tri(Quad)state dann:  01FDD01F00D0

Interessant: Lighting4 disabled ARC gar nicht mehr und funktioniert. Das war früher anders(steht auch noch im FHEM-Wiki so).

Senden hat bei mir nicht funktioniert. Liegt vermutlich am falschen(405 vs. 350) Basispuls. Den können wir aber nicht beeinflussen, oder ? Edit: Mit dem RFXMGR lässt sich der Basispuls definieren und dann funktioniert das Senden auch. 

Grüße Markus

Edit2: In TRX_Light ist für PT2262 der Basispuls 350(15E) fest verdrahtet. Ich hab jetzt mal testweise auf 405(195) codiert. Klappt.  Wir könnten also für PT2262-devices ein Attribut ITclock(so heißt es bei IT-/CUL-devices) einführen. Auch könnten wir ein Reading/Internal einführen, welches den empfangenen Basispuls anzeigt.