Temperatursender von Wetterstation in CUL

[bjoernh]

Der Eurochron EAS 800 Z funktioniert inzwischen auf dem SIGNALduino wie gewünscht.
Beim EAS 800 Z ist mir folgendes aufgefallen. Er ist nur bedingt außentauglich, da die Batterieabdeckung keine Gummilippe hat und nur gesteckt ist.
Ich mußte im Modul einige Plausibilitäts- und Werteüberprüfungen einbauen, da das Protokoll keine Prüfsumme hat.

Das dafür erforderliche neue Modul ist so gut wie fertig. Danke an Sidey für die Hilfe.
Da ich von dem EAS 800 Z nicht vorhabe mehr als drei zu kaufen, enthält der devicecode des EAS 800 Z per default nur den Kanal.
Damit bleibt beim Batterewechsel der devicecode gleich.

Damit auch mehr als 3 Sensoren benutzt werden können, habe ich im Hauptmodul 00_SIGNALduino.pm das "attr devicecodeWithId" hinzugefügt.
Damit kann man bei Bedarf festlegen, daß der devicecode zusätzlich zum Channel auch die ID enthält. Z.B. EAS800z_4E2 bei ID=4E und Channel 2.

Es wäre schön, wenn man beim attr "devicecodeWithId" die Module einzeln festlegen könnte wie beim room attr,
dazu reichen meine Kenntnisse aber nicht aus.
Ist so ein Auswahlfenster, bei dem mehrere optionen ausgewählt werden können,  wie beim "attr room" aufwendig und komplizert zu programmieren? Gibt es dafür Beispiele?

Gruß Ralf

Hallo Ralf,

kannst Du mir mal von dem Sensor ein paar messwerte inkl. den signalduino Ausgaben schreiben?
Ich hab nämlich jetzt dann eine Idee wie ich das in die a-culfw bekomme.

Gruß
Björn

[Ralf9]

kannst Du mir mal von dem Sensor ein paar messwerte inkl. den signalduino Ausgaben schreiben?
Ich hab nämlich jetzt dann eine Idee wie ich das in die a-culfw bekomme.

Hallo Björn,

hier sind 2 Messwerte. Sind diese ausreichend oder brauchst Du noch mehr?

Code Auswählen Erweitern

SIGNALduino/msg READ: MS;P0=481;P1=-980;P2=-1958;P3=-3903 D=03010201010202020102010102010101010201020101010102020202020102010102010102;CP=0;SP=3;
decoded Hex: 4E90A1F49
ID7_Parse converted to bits: 01001110 1 001 000010100001 1111 01001001
ID7_Parse decoded protocolid 7: sensor id=4E, channel=2, temp=16.1, hum=73, bat=ok

Code Auswählen Erweitern

SIGNALduino/msg READ: MS;P0=484;P1=-981;P2=-1957;P3=-1224;P4=240;P5=-3913;P6=1371;D=05010201010202020102010102010101010201010202020101020202020102010102010202;CP=0;SP=5;
decoded Hex: 4E909CF4B
ID7_Parse converted to bits: 01001110 1 001 000010011100 1111 01001011
ID7_Parse decoded protocolid 7: sensor id=4E, channel=2, temp=15.6, hum=75, bat=ok

Gruß Ralf

[bjoernh]

Hallo Björn,

hier sind 2 Messwerte. Sind diese ausreichend oder brauchst Du noch mehr?

Code Auswählen Erweitern

SIGNALduino/msg READ: MS;P0=481;P1=-980;P2=-1958;P3=-3903 D=03010201010202020102010102010101010201020101010102020202020102010102010102;CP=0;SP=3;
decoded Hex: 4E90A1F49
ID7_Parse converted to bits: 01001110 1 001 000010100001 1111 01001001
ID7_Parse decoded protocolid 7: sensor id=4E, channel=2, temp=16.1, hum=73, bat=ok

Code Auswählen Erweitern

SIGNALduino/msg READ: MS;P0=484;P1=-981;P2=-1957;P3=-1224;P4=240;P5=-3913;P6=1371;D=05010201010202020102010102010101010201010202020101020202020102010102010202;CP=0;SP=5;
decoded Hex: 4E909CF4B
ID7_Parse converted to bits: 01001110 1 001 000010011100 1111 01001011
ID7_Parse decoded protocolid 7: sensor id=4E, channel=2, temp=15.6, hum=75, bat=ok

Gruß Ralf

Hallo Ralf,

ist schonmal super. Hast Du auch Werte dazu?
Bzw. wisst Ihr schon wie er berechnet wird.
Wird der bereits mit dem TCM Modul dekodiert?

Gruß
Björn

[Sidey]

Hi Björn,

der TCM_97001 Sensor verwendet eine andere Modulation.

Der von Ralf beschriebene Sensor verwendet folgende Modulation:

Code Auswählen Erweitern


                        one => [1,-4],
zero => [1,-2],
sync => [1,-8],
clockabs      => 484,


Der von TCM_97001 verwendete encoder erzeugt folgende Molulation

Code Auswählen Erweitern


one => [1,-8],
zero => [1,-4],
sync => [1,-18],
clockabs    => '500',


Wir haben bislang zwei Sensortypen gefunden, welche diesen encoder verwenden:
*Temp + Feuchte
*Temp


Für die Einbindung in FHEM haben wir ein Modul entwickelt:
https://github.com/RFD-FHEM/RFFHEM/blob/dev-proto7/FHEM/14_SIGNALduino_ID7.pm

So ganz fertig sind wir aber noch nicht.


Grüße Sidey

[bjoernh]

Hi Björn,

der TCM_97001 Sensor verwendet eine andere Modulation.

Der von Ralf beschriebene Sensor verwendet folgende Modulation:

Code Auswählen Erweitern


                        one => [1,-4],
zero => [1,-2],
sync => [1,-8],
clockabs      => 484,


Der von TCM_97001 verwendete encoder erzeugt folgende Molulation

Code Auswählen Erweitern


one => [1,-8],
zero => [1,-4],
sync => [1,-18],
clockabs    => '500',


Wir haben bislang zwei Sensortypen gefunden, welche diesen encoder verwenden:
*Temp + Feuchte
*Temp


Für die Einbindung in FHEM haben wir ein Modul entwickelt:
https://github.com/RFD-FHEM/RFFHEM/blob/dev-proto7/FHEM/14_SIGNALduino_ID7.pm

So ganz fertig sind wir aber noch nicht.


Grüße Sidey

Dass der Sensor kürzere Zeiten hat, habe ich gesehen.
Ich muss mir nur was einfallen lassen, wie ich auf den Sync reagiere. Der Punkt ist ja, wenn ich auf einen Sync mit >4500 lausche, bekomme ich die TCMs, wenn ich aber nun > 3500 nehme bekomme ich probleme mit dem Low bit des TCMs, dieser ist ja bei 4000.
Aber ich bin da Zuversichtlich.
Ich werde das jetzt mal ein bauen, vielleicht hört mein CUL ja so einen Sensor in der Gegend.

Wieso lasst Ihr die Dekodierung nicht trotzdem das TCM Modul machen, das sollte doch problemlos gehen.

 

[Sidey]

Hi Björn,

Dass der Sensor kürzere Zeiten hat, habe ich gesehen.
Ich muss mir nur was einfallen lassen, wie ich auf den Sync reagiere. Der Punkt ist ja, wenn ich auf einen Sync mit >4500 lausche, bekomme ich die TCMs, wenn ich aber nun > 3500 nehme bekomme ich probleme mit dem Low bit des TCMs, dieser ist ja bei 4000.
Aber ich bin da Zuversichtlich.

Ein Sync ist alles wo ein kurzer Puls high und anschließend ein n* so lang Puls low kommt. Ich hab den Wert auf mindestens 7 oder 8x gesetzt.
Wie lange er dann absolut ist, spielt eigentlich keine Rolle, da das ja vom Takt abhängt.

Wieso lasst Ihr die Dekodierung nicht trotzdem das TCM Modul machen, das sollte doch problemlos gehen.

Weil er einen anderen encoder verwendet und nicht den encoder, der in diesem TCM Modul enthalten ist.
Ebenso hätten wir es ja in jedes andere Modul sonst einbauen können.

Grüße Sidey

[bjoernh]

Hi Björn,
Ein Sync ist alles wo ein kurzer Puls high und anschließend ein n* so lang Puls low kommt. Ich hab den Wert auf mindestens 7 oder 8x gesetzt.
Wie lange er dann absolut ist, spielt eigentlich keine Rolle, da das ja vom Takt abhängt.


Weil er einen anderen encoder verwendet und nicht den encoder, der in diesem TCM Modul enthalten ist.
Ebenso hätten wir es ja in jedes andere Modul sonst einbauen können.

Grüße Sidey

Genau, kurzer impuls und dann ein langer, das ist der Sync. Der CUL lauscht auf diesen und startet dann den Empfang der restlichen bits.

Das TCM Modul hat ja bereits schon einige verschiedene decoder enthalten, da würde es auf einen mehr auch nicht mehr ankommen

Ich glaube so langsam sollte man das Modul umbenennen, dies ist aber leider nicht so einfach möglich, da dann die ganzen Einstellungen in Fhem weg sind.

Ich habs übrigens jetzt in der a-culfw drinnen. Jetzt brauche ich nur noch jemanden der es mal testet. Ich höre leider bei mir im Umkreis keinen solchen Sensor.

[Sidey]

Hi Björn,

zwischen den zwei Pulsen gibt es einen Faktor. Der 1. High Puls entspricht einem Takt. Der Sync Puls dann mehrfach dem Takt.
Die 0 und 1 Bits entsprechen auch immer einem vielfachen des Taktes. Durch die Länge des Faktors ergibt sich in der Regel, was ist Sync, was ist 0 und was ist eine 1.

Das TCM Modul hat ja bereits schon einige verschiedene decoder enthalten, da würde es auf einen mehr auch nicht mehr ankommen

Ich meinte encoder die das Signal modulieren. Nicht das Protokoll.
Alle Sensoren, welche durch TCM_97001 unterstützt werden nutzen doch alle die gleiche Modulation.
Für jede Modulation ein eigenes Modul zu spendieren, halte ich nicht für falsch. Sonst wird das doch irgendwann zu unübersichtlich.


Bei dem genannten EAS 800 und noch anderen Sensoren deren Namen ich nicht kenne, wird eine andere Modulation verwendet.
Irgendwo muss man halt auch mal eine Grenze ziehen, welchen Sensor man noch in ein Modul packt und welchen nicht. Die Modulation halte ich da für eine brauchbare Unterscheidung.
Irgendwie dachte ich, dass auch schon mal besprochen zu haben.

Grüße Sidey

[Ralf9]

Ich habs übrigens jetzt in der a-culfw drinnen. Jetzt brauche ich nur noch jemanden der es mal testet. Ich höre leider bei mir im Umkreis keinen solchen Sensor.

Also ich habe diesen Eurochron, leider wird er über die alternative CUL Firmware nicht erkannt. Wenn ihr in diese Richtung Tester braucht stelle ich mich wie gesagt gerne zur Verfügung.

Hallo Joker2002,

hast Du z.Zt. die Möglichkeit den Eurochron mit der aktuellen a-culfw zu testen?

Gruß Ralf

[bjoernh]

Hi Björn,

zwischen den zwei Pulsen gibt es einen Faktor. Der 1. High Puls entspricht einem Takt. Der Sync Puls dann mehrfach dem Takt.
Die 0 und 1 Bits entsprechen auch immer einem vielfachen des Taktes. Durch die Länge des Faktors ergibt sich in der Regel, was ist Sync, was ist 0 und was ist eine 1.


Ich meinte encoder die das Signal modulieren. Nicht das Protokoll.
Alle Sensoren, welche durch TCM_97001 unterstützt werden nutzen doch alle die gleiche Modulation.
Für jede Modulation ein eigenes Modul zu spendieren, halte ich nicht für falsch. Sonst wird das doch irgendwann zu unübersichtlich.


Bei dem genannten EAS 800 und noch anderen Sensoren deren Namen ich nicht kenne, wird eine andere Modulation verwendet.
Irgendwo muss man halt auch mal eine Grenze ziehen, welchen Sensor man noch in ein Modul packt und welchen nicht. Die Modulation halte ich da für eine brauchbare Unterscheidung.
Irgendwie dachte ich, dass auch schon mal besprochen zu haben.

Grüße Sidey

Hallo,

so, jetzt habe ich mir das Protokoll mal genauer angesehen.

Folgendes habe ich jetzt verstanden:

Code Auswählen Erweitern

SIGNALduino/msg READ: MS;P0=481;P1=-980;P2=-1958;P3=-3903 D=03010201010202020102010102010101010201020101010102020202020102010102010102;CP=0;SP=3;
decoded Hex: 4E90A1F49
ID7_Parse converted to bits: 01001110 1 001 000010100001 1111 01001001
ID7_Parse decoded protocolid 7: sensor id=4E, channel=2, temp=16.1, hum=73, bat=ok

01 entspricht 0
02 entspricht 1

03 (Sync)
01 02 01 01 0100
02 02 02 01 1110
02 01 01 02 1001
01 01 01 01 0000
02 01 02 01 1010
01 01 01 02 0001
02 02 02 02 1111
01 02 01 01 0100
02 01 01 02 1001

0100 1110 1001 0000 1010 0001 1111 0100 1001
A    B    C    D    E    F    G    H    I
 
A+B = ID = 4E
C Bit 0 = Bat (1) OK
C Bit 1-3 = Channel 001 = 1
D-F = Temp (0000 1010 0001) = 161 ~ 16,1°
G = Unknown
H+I = hum (0100 1001) = 73


Es funktioniert im großen und ganzen genauso wie das TCM, aber doppelt so schnell.
Die a-culfw müsste das nach meiner Anpassung genauso wie ein TCM ausspucken, also mit s....
Das Modul müsste es weitestgehend auch schon können.

Was ich mich aber noch frage, ist folgendes:
Das Packet C enthält den Batteriestatus sowie den Channel. Hat der Sender keine TX Taste? Wenn ja. müsste sich diese in diesem Bucket verstecken.
Ist das Bucket G immer 1111?


@Ralf9 Hast Du einen cul oder nanocul? Wenn ja, darf ich dir mal eine Testfirmware zusenden?
Ich würde nämlich gerne vor dem veröffentlichen den Empfang mit eingeschaltetem X25 sehen.

[Sidey]

Hi Björn,

Ja das ist immer 0xf bei zwei getesteten Sensoren.
Darauf wird auch in dem verlinkten Modul gefiltert.

Wir haben nur noch keinen gescheiten Namen dafür.

Grüße Sidey

[bjoernh]

Hi Björn,

Ja das ist immer 0xf bei zwei getesteten Sensoren.
Darauf wird auch in dem verlinkten Modul gefiltert.

Wir haben nur noch keinen gescheiten Namen dafür.

Grüße Sidey

OK, dann werde ich das bei mir auch so berücksichtigen.
Ja, wie gesagt, der name für das TCM gefällt mir auch nicht so richtig, da ist ja auch alles möglich drinnen. Ich kann es aber nicht so einfach umbenennen.

[Ralf9]

@Ralf9 Hast Du einen cul oder nanocul? Wenn ja, darf ich dir mal eine Testfirmware zusenden?
Ich würde nämlich gerne vor dem veröffentlichen den Empfang mit eingeschaltetem X25 sehen.

Ich warte erst mal ab ob Joker2002 eine Möglichkeit zum Testen hat. Ich müsste dazu erstmal was umbauen.

Gruß Ralf

[Sidey]

OK, dann werde ich das bei mir auch so berücksichtigen.
Ja, wie gesagt, der name für das TCM gefällt mir auch nicht so richtig, da ist ja auch alles möglich drinnen. Ich kann es aber nicht so einfach umbenennen.

Jo, alles was den gleichen Signalcodierung verwendet, deshalb verstehe ich nicht, wieso Du jetzt noch andere Signale in dieses Modul packen willst.


Grüße Sidey

[Joker2002]

Hi, ich kanns gerne mal testen, wird allerdings noch bis nächste Woche dauern, da ich derzeit leider nicht all zu viel Zeit habe