Signalduino Entwicklung

[Sidey]

Hallo Ralf,

Ich habe nun den Eurochron EAS 800 Z an den SIGNALduino angeschlossen und mitgeloggt. Die ersten drei logs habe ich erzeugt durch drücken der reset-Taste am Sensor.

Prima, nachdem ich die ersten Zeilen deines Loggs gesehen hatte, dachte ich auch. Alles in Butter. Dekodierung funktioniert ja.
Naja, das was ich als Eurochron implementiert habe, passt nicht zu deinem Sensor.


Macht aber nichts, es passt so einigermaßen zu den Daten eines anderen Sensors, zu dem Anfichtn mir bereits Daten gesendet hatte. Allerdings hatte seiner keine Feuchtigkeit. Die Ausgaben zum TX70DHT kannst Du ignorieren. Ich hatte mal angenommen, der sendet mit dem kleinen Funkprotokoll.
Eventuell stimmt das auch

Nachdem ich die Bits ihren Bedeutungen zugeordnet habe, hier die Dekodierte Nachricht:

Code Auswählen Erweitern


2015.09.15 01:22:56 4: devSduino decoded protocolid: 7 (EAS800z / type=3) mode=auto, sensor id=8, channel=1, temp=25.9, hum=64, bat=ok
2015.09.15 01:22:56 4: devSduino decoded protocolid: 7 (TX70DTH) sensor id=38, channel=0, temp=0.3, hum=64, bat=ok
2015.09.15 01:22:56 4: devSduino converted to bits: 0011100010000001000000111111010000000000
2015.09.15 01:22:56 4: devSduino incomming u7388103F400
2015.09.15 01:22:56 4: devSduino decoded protocolid: 7 (EAS800z / type=3) mode=auto, sensor id=8, channel=1, temp=25.9, hum=64, bat=ok
2015.09.15 01:22:56 4: devSduino decoded protocolid: 7 (TX70DTH) sensor id=38, channel=0, temp=0.3, hum=64, bat=ok
2015.09.15 01:22:56 4: devSduino converted to bits: 0011100010000001000000111111010000000000
2015.09.15 01:22:56 4: devSduino incomming u7388103F400
2015.09.15 01:22:56 5: devSduino dispatch u7388103F400


Wo ich mir nicht ganz sicher bin.
Negative Temperaturen.
Batteriestatus
Sensor ID / Sensor Typ.

Ansonsten bleibt mir nur zu sagen, dass deine Daten echt prima waren. So konnte ich doch schnell erkennen wo welche Daten stehen.

Diese Daten sind evtl auch in den obrigen logs enthalten. Ich kann sie zu keinem meiner Sensoren zuorndnen.

Code Auswählen Erweitern

2015.09.14 19:01:40 4: SIGNALduino/msg READ: MS;P0=477;P1=-1998;P2=-4109;P3=-8914;D=03010201010202010201020101020102010102010201010101020101020201010202020202;CP=0;SP=3;
Gruß Ralf
[/quote]


Das sieht so wie ein Logilink, Perl, NC_WS, TCM... Sensor aus. Da sind 36 Bit, die sollten an das Modul cul_tcm97001 gesendet werden. Wenn es ein bekannter Sensor ist, dann wird er mittels autocreate angelegt.


So. Jetzt fehlt nur noch ein Modul für den EAS 800z
Grüße Sidey

[Ralf9]

Nachdem ich die Bits ihren Bedeutungen zugeordnet habe, hier die Dekodierte Nachricht:

Danke, für Deine gute Arbeit. Das sieht so gut aus.

So. Jetzt fehlt nur noch ein Modul für den EAS 800z

Wenn ich das richtig sehe, müsste das ein gemeinsames Modul für "TX70DTH" und dem "EAS800z" sein. Das Modul müsste dann irgendwie zwischen dem beiden Sensoren unterscheiden.


Ich würde den Signalduino gerne produktiv einsetzen, vom Arduino werden mir aber noch zu viele Daten empfangen.
Es wäre schön, wenn es auf dem Arduino eine configoption geben würde, bei der die "MU messages" unterdrückt würden. 

Ich habe gesehen, daß es auch den Befehl "F" changeFilter (ADD entry to filter list  <Syncfact>;<clock>) gibt. Was hat es damit auf sich?

Gruß Ralf

[Sidey]

Hallo Ralf,

Danke, für Deine gute Arbeit. Das sieht so gut aus.
Wenn ich das richtig sehe, müsste das ein gemeinsames Modul für "TX70DTH" und dem "EAS800z" sein. Das Modul müsste dann irgendwie zwischen dem beiden Sensoren unterscheiden.

Fast. Also ob TX70DHT das gleiche Funkprotokoll verwendet weiss ich nicht. Es könnte sein, es gab Anhaltspunkte. Leider wurden die bislang nicht bestätigt.
Ich glaube es gibt auch Sensoren von "Auriol", oder "Pollin" z.B. (EWS-151) und Velleman WS8426S welche exakt das gleiche Protokoll nutzen.

Also zielführender ist es ein Modul zu entwickeln, welches das Funkprotokoll unterstützt. Da wir den verwendeten Chipsatz nicht kennen, nenne es einfach weather2 oder sonst wie.

Ich würde den Signalduino gerne produktiv einsetzen, vom Arduino werden mir aber noch zu viele Daten empfangen.

Ist der Äther bei dir auch so verpestet wie bei mir 

Es wäre schön, wenn es auf dem Arduino eine configoption geben würde, bei der die "MU messages" unterdrückt würden. 

Ich habe gesehen, daß es auch den Befehl "F" changeFilter (ADD entry to filter list  <Syncfact>;<clock>) gibt. Was hat es damit auf sich?

Im Signalduino war mal ein Filter (whitelist) eingebaut, die von FHEM aus programmiert wurde. Ich habe das aber verworfen, denn man kann den Speicher erst mal nicht groß genug dafür dimensionieren. Zum anderen, sucht man ein Protokoll, das noch nicht bekannt ist findet man es auch nicht, da es gefiltert wird.

Aktuell ist das Verhalten, alles was wie ein Funksignal aussieht, wird an FHEM übergeben. Dort bist Du dann frei zu entscheiden was passieren soll. Geplant ist, eine dynamische Liste der logischen Module zu ermöglichen. Aktuell habe ich das noch nicht implementiert.

Was stört dich denn aktuell daran, dass alles in FHEM landet? Wenn es nur das logfile ist, dann kannst Du den loglevel einfach herunter drehen.

Grüße Sidey

[Ralf9]

Was stört dich denn aktuell daran, dass alles in FHEM landet? Wenn es nur das logfile ist, dann kannst Du den loglevel einfach herunter drehen.

Hallo Sidey,

mir gehts nur um die Nachrichten die unvollständig oder gar kein Signal sind. Es wäre schön, wenn es eine Option geben würde diese zu unterdrücken.
Im produktiven Betrieb dürften diese nicht interessant sein. Ich wollte in fhem unnötigen Ressorcen- und Rechenleistungsverbrauch vermeiden, oder ist dies nicht relevant?

Im Wiki steht dazu folgendes:

Code Auswählen Erweitern

MU - Message unsynced: Diese Art von Nachrichten, sind nicht nach Manchester codiert und diese haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht.
Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist

Gruß Ralf

[Sidey]

Im produktiven Betrieb dürften diese nicht interessant sein. Ich wollte in fhem unnötigen Ressorcen- und Rechenleistungsverbrauch vermeiden, oder ist dies nicht relevant?

Nun gut, ich kann nicht behaupten es würde keinerlei Ressourcen verbrauchen, aber das fällt vermutlich kaum ins Gewicht.

Im Wiki steht dazu folgendes:

Code Auswählen Erweitern

MU - Message unsynced: Diese Art von Nachrichten, sind nicht nach Manchester codiert und diese haben auch keinen erkennbaren Sync / Clock Signalpegel am Start der Nachricht.
Bei diesen Nachrichtentypen ist es, im Vergleich zu den anderen, am wahrscheinlichsten, dass das übermittelte Signal unvollständig oder überhaupt kein Signal ist

Ja, stimmt. In der Regel handelt es sich um ein Signal, dafür sorgt der Signalduino bereits. Es kann mal vorkommen, dass auch etwas als signal erkannt wird, welches keines ist. Das passiert immer dann, wenn das rauschen nach einem Muster und nicht zufällig erfolgt. Also eher selten.
Was schon eher passieren kann sind unvollständige Nachrichten. Insbesondere, die erste Übertragung einer Nachricht wird eigentlich nie komplett empfangen.

Ich könnte natürlich eine Option einbauen die folgende drei Signaltypen auf dem signalduino aktiviert oder deaktiviert:
pulspause mit sync
manchester
sonstige

Dann könntest Du die sonstigen deaktivieren, solange Du keinen Sensor mit so einem Signaltyp empfangen möchtest.

Was mich aber interessiert, wie oft kommen die Nachrichten vom Typ MU denn bei dir? Kannst ja auch mal ein paar posten.


Grüße Sidey

[Ralf9]

Ich könnte natürlich eine Option einbauen die folgende drei Signaltypen auf dem signalduino aktiviert oder deaktiviert

Ja, das würde die unnötigen Nachrichten reduzieren. Ist aber momentan nicht so dringend. Ich habe momentan nur ein paar Sensoren.
Ich möchte im Haus meiner Eltern ca 10 Temperatursensoren einbinden, mal schauen wie es dann aussieht.

Die Nachrichten vom Typ MU halten sich bis jetzt noch in Grenzen. Hier sind einige.
Die letzten 4 sind von einem älteren Oregon Temperatursensor.

Code Auswählen Erweitern

2015.09.15 23:57:26 4: SIGNALduino/msg READ: MU;P0=1772;P1=-1156;P2=3240;P3=-2622;D=01230121030121010301230101010101210321030122;CP=0;
2015.09.15 23:57:26 4: SIGNALduino/msg READ: MU;P0=1792;P1=-1141;P2=3257;P3=-2598;D=01230121030121010301230101010101210321030122;CP=0;
2015.09.15 23:57:45 4: sduino: GetUpdate called ...
2015.09.15 23:57:56 4: SIGNALduino/msg READ: MU;P0=1857;P1=-1070;P2=3269;P3=-2596;P4=-32001;P5=-4096;P6=1368;D=01230101012321010301230101010101010121010301240101010101010101010101050;CP=0;
2015.09.15 23:57:56 4: SIGNALduino/msg READ: MU;P0=128;P1=3298;P2=-1090;P3=1826;P4=-2561;P5=-32001;P6=1368;D=12343214323232141232343214323232323232321232343215020;CP=3;
2015.09.15 23:58:15 4: sduino: GetUpdate called ...
2015.09.15 23:58:26 4: SIGNALduino/msg READ: MU;P0=3220;P1=-1118;P2=1809;P3=-2640;P4=-32001;P5=-4144;P6=1368;D=012321032121012321012321032121212121210121232121042121212121212121212121250;CP=2;
2015.09.15 23:58:26 4: SIGNALduino/msg READ: MU;P0=112;P1=3254;P2=-1144;P3=1783;P4=-2606;P5=-32001;P6=1368;D=1234321432321234321234321432323232323212323432321501;CP=3;


Von der Empfangsempfindlichkeit und -qualität des Superheterody Receivers bin ich übrigens begeistert, es sind Welten unterschied zum Cul.

Gruß Ralf

[Ralf9]

ich habe mal versucht das Modul für den EAS800z zu programmieren. Es passt noch nicht ganz.

Ich bekomme die folgende Meldung nicht weg.

Code Auswählen Erweitern

sduino: Unknown code u75690D5F3E0, help me!

Mir ist es auch nicht gelungen daß der Sensor automatisch defined wird. Nachdem ich ihn von Hand definiert habe, werden die Werte in die Readings geschrieben. Im "Event monitor" und im Filelog wird aber nichts angezeigt.

Code Auswählen Erweitern

define EAS800z_49 SIGNALduino_ID7 49

Ich habe das Modul "14_SIGNALduino_ID7.pm" genannt und in der 00_SIGNALduino.pm bei "my $clientsSIGNALduino" und "my %matchListSIGNALduino" eingetragen.

Gruß Ralf

[Sidey]

Hallo Ralf,

ich schätze, Du hast dir da ein schlechtes Modul als Vorlage genommen.

Wir hatten hier die letzten Tage das Thema schon mal für Cresta Sensoren.

Einige Posts zuvor hatte ich ein minimalmodul erstellt.
Nimm doch das und benenne die Stellen mit suchen / ersetzen um und baue dort die Dekodierung der Bits ein.

Ich kann in Github einen Zweig für die Entwicklung aufnehmen, dann kann ich und auch andere leicht Korrekturen vornehmen.
Hast Du da einen account?

Grüße Sidey

[Ralf9]

Hast Du da einen account?

Nein ich habe noch keinen account? Gibt es für den Github eine gute Anleitung?

Gruß Ralf

[Sidey]

Hi,

schwer zu sagen, was gut ist.

Schau dir mal die an:
https://www.mittwald.de/blog/webentwicklung-webdesign/webentwicklung/versionsverwaltung-einfuhrung-in-git-teil-1

[Ralf9]

Hast Du da einen account?

Ich habe unter "Ralf9" einen account angelegt

[Sidey]

Gut, Du bist eingeladen

den Zweig habe ich auch erstellt und erst mal deine perl Datei eingefügt:

https://github.com/RFD-FHEM/RFFHEM/tree/dev-proto7

[pejonp]

Hallo Sidey,

so wir der Battetriestatus im FHEM/14_Cresta.pm programmiert ist, funktioniert er bei meinem Bresser ThermoHygro. Ich habe es auch mit fast leeren Bat getestet. Es wird in FHEM und im Sensor angezeigt. Gute Arbeit. 2 Sachen habe ich beim dev-cresta noch angepaßt .

jörg

[Ralf9]

..funktioniert er bei meinem Bresser ThermoHygro.

Hallo Jörg,

wie heißt dieser Bresser ThermoHygro? Hat er mehr als 3 Kanäle? Falls ja, hast Du auch schon mal getestet ob auch bei Kanal 4 + 5 der Kanal richtig angezeigt wird?

Gruß Ralf

[Sidey]

Hallo,

ich hab noch mal über die minsecs und equal MSG Option in den logischen Modulen nachgedacht.

Ich glaube die können entfallen.
Man kann alles mit event-on-update,  event-on-change-reading und event-minintervall einstellen.

http://www.fhemwiki.de/w/index.php?title=Event-on-change-reading&redirect=no

Ich denke, wir können die eigenen Parameter entfernen.

Grüße Sidey