Signalduino Entwicklung

Hardlife · 09 Januar 2016, 18:59:00

Hi Ralf!

Gesagt, getan...
Die MU-Nachrichten sind nun weg...

Leider bleibt der Fehler:

2016.01.09 18:40:18 4: SIGNALduino/msg READ: MS;P0=365;P1=870;P2=-1093;P3=-606;P4=-8428;D=1412121212121212121212121212121213020313020;CP=1;SP=4;O;
2016.01.09 18:40:19 4: SIGNALduino/msg READ: MS;P0=349;P1=-1040;P2=1045;P3=-346;P4=-10771;D=04012323010101230101230101232323012323010123010123;CP=0;SP=4;O;
2016.01.09 18:40:19 4: Founded matched MS Protocol id 3 -> itv1
2016.01.09 18:40:19 4: Decoded matched MS Protocol id 3 dmsg i624EC9 length 24
2016.01.09 18:40:19 4: SIGNALduino/msg READ: MS;P0=-1045;P1=1042;P2=-351;P3=347;P4=-10780;D=34301212303030123030123030121212301212303012303012;CP=3;SP=4;O;
2016.01.09 18:40:19 4: Founded matched MS Protocol id 3 -> itv1
2016.01.09 18:40:19 4: Decoded matched MS Protocol id 3 dmsg i624EC9 length 24
2016.01.09 18:40:19 4: Dropped (i624EC9) due to short time or equal msg
2016.01.09 18:40:20 4: SIGNALduino/msg READ: MS;P0=1047;P1=-343;P2=350;P3=-1042;P4=-10786;D=24230101232323012323012323010101230101232301232301;CP=2;SP=4;O;
2016.01.09 18:40:20 4: Founded matched MS Protocol id 3 -> itv1
2016.01.09 18:40:20 4: Decoded matched MS Protocol id 3 dmsg i624EC9 length 24
2016.01.09 18:40:20 4: Dropped (i624EC9) due to short time or equal msg
2016.01.09 18:40:20 4: SIGNALduino/msg READ: MS;P0=-1040;P1=1052;P2=-340;P3=351;P4=-10784;D=34301212303030123030123030121212301212303012303012;CP=3;SP=4;O;
2016.01.09 18:40:20 4: Founded matched MS Protocol id 3 -> itv1
2016.01.09 18:40:20 4: Decoded matched MS Protocol id 3 dmsg i624EC9 length 24
2016.01.09 18:40:20 4: Dropped (i624EC9) due to short time or equal msg
2016.01.09 18:40:22 4: SIGNALduino/msg READ: MS;P0=335;P1=-1056;P2=1033;P3=-358;P4=-10784;D=04012323010101230101230101232323012323010123010123;CP=0;SP=4;O;
2016.01.09 18:40:22 4: Founded matched MS Protocol id 3 -> itv1
2016.01.09 18:40:22 4: Decoded matched MS Protocol id 3 dmsg i624EC9 length 24
2016.01.09 18:40:22 4: SIGNALduino/msg READ: MS;P0=-1045;P1=1046;P2=-348;P3=346;P4=-10783;D=34301212303030123030123030121212301212303012303012;CP=3;SP=4;
2016.01.09 18:40:22 4: Founded matched MS Protocol id 3 -> itv1
2016.01.09 18:40:22 4: Decoded matched MS Protocol id 3 dmsg i624EC9 length 24
2016.01.09 18:40:22 4: Dropped (i624EC9) due to short time or equal msg
2016.01.09 18:40:25 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:26 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:27 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:32 1: Error: unknown tristate in "101001" has no TYPE
2016.01.09 18:40:32 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:33 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
2016.01.09 18:40:34 1: PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.

Wenn ich die Funktion

Code Auswählen

#include <patternDecoder.h> //Logilink, IT decoder
in der RF_Receiver.ino deaktiviere, und die Firmware selbst kompiliere, müsste die Tristate-Umrechnung doch aus sein?

Ralf9 · 09 Januar 2016, 19:20:15

Zitat von: Hardlife am 09 Januar 2016, 18:59:00
Wenn ich die Funktion
Code Auswählen Erweitern
#include <patternDecoder.h> //Logilink, IT decoder
in der RF_Receiver.ino deaktiviere, und die Firmware selbst kompiliere, müsste die Tristate-Umrechnung doch aus sein?

In der RF_Receiver.ino würde ich nichts ändern.

Vielleicht hat Sidey noch eine Idee?

Gruß Ralf

Hardlife · 09 Januar 2016, 21:07:14

Danke für Deine Unterstützung.

Dann warte ich mal, ob Sidey vielleicht was einfällt.

LG,
Hardlife

Sidey · 09 Januar 2016, 22:28:47

Hallo Hardlife,

Zitat von: Hardlife am 09 Januar 2016, 13:51:19
Die Fehlermeldung aus dem FHEM-Log:
Code Auswählen Erweitern
1: Error: unknown tristate in "101001" has no TYPE
danach wiederholt sich im Log die von FHEM stammende Fehlermeldung
Code Auswählen Erweitern
PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4519.
hunderte Male

Die Meldung kommt aus dem IT Modul. Der SIGNALduino hat etwas empfangen, das ein ITv3 Signal zu sein scheint.
Das übergibt er dann an das IT Modul in FHEM. Dort wird versucht das ganze zu dekodieren, allerdings funktioniert das nicht.

Der Grund liegt daran, dass das IT Modul die Daten in einem anderen Format benötigt.
Ich selbst habe leider kein ITv3 Gerät und habe selbst keine ausreichenden Testdaten um das ganze mal zu analysieren.

Zitat von: Hardlife am 09 Januar 2016, 13:51:19
Meine Vermutung (bitte nicht schlagen, falls ich völlig daneben liege, ist eine reine Mutmaßung) ist,
daß der Signalduino ein ihm fremdes Signal (keine Ahnung, hier funkt vieles auf 433 rum) empfängt.
Er rechnet auch einen Tristate aus/um? und übergibt die Meldung an FHEM, welches aber wegen fehlendem Type scheitert?

Nicht ganz. Der SIGNALDuino (Arduino) erkennt keinen Tristate. Der erkennt nur Signale.
Die Signale werden in FHEM im SIGNALDuino Modul in Bits umgerechnet.

Zitat von: Hardlife am 09 Januar 2016, 13:51:19
weitere Devices, die der Signalduino ausfindig macht wären (aus dem Log):
Code Auswählen Erweitern
DDD0D10010D1D0D10010D1D0D101D not defined (Address: DDD0D10010D1D0D10010D1D0D1 Group: 0 Unit: 1D Switch code: 0)
und
Code Auswählen Erweitern
DDDD0DDD010D1DD0DDD010D1DD0DD01 not defined (Address: DDDD0DDD010D1DD0DDD010D1DD Group: 0 Unit: DD01 Switch code: D)
Das scheint FHEM aber trotz des "komischen" IT-V3?-Codes keine Bauchschmerzen zu bereiten oder ist das etwa die Wurzel allem Übels???

Ich nehme an, diese Geräte werden aber auch nicht via Autocreate angelegt.

Lösen lässt sich das ganze nun, in dem man ITv3 nicht auf die Whitelist setzt oder mir jemand hilft das ITV3 Protokoll zu implementieren.

Grüße Sidey

Hardlife · 10 Januar 2016, 13:16:31

Hi Sidey!

Danke, daß Du Dich meinem Problem annimmst und vielen Dank für die Arbeit am Signalduino. Echt ein tolles Stück.
Ich irre hier ja aufgrund fehlender Tiefenkenntnisse wie der Blinde durch den Wald...

ZitatDie Meldung kommt aus dem IT Modul. Der SIGNALduino hat etwas empfangen, das ein ITv3 Signal zu sein scheint.
Das übergibt er dann an das IT Modul in FHEM. Dort wird versucht das ganze zu dekodieren, allerdings funktioniert das nicht.
Der Grund liegt daran, dass das IT Modul die Daten in einem anderen Format benötigt.

Verstehe. Darum wirft das IT-Modul auch einen für IT-V3 unüblichen Tristate mit "D" aus.
Meine IT-V3-Codes bestehen ja nur aus 0 und 1. Meine IT-V1-Codes aus 0 und F.

ZitatIch nehme an, diese Geräte werden aber auch nicht via Autocreate angelegt.

Korrekt, da der D01-Tristate von FHEM nicht als IT-V3 akzeptiert wird... (eben nur 0 und 1)

Darum also auch die Meldung mit dem nicht vorhandenen Type:

Code Auswählen

Error: unknown tristate in "101001" has no TYPE
Weil es ja auch kein TYPE IT-V3 ist/darstellt.

ZitatLösen lässt sich das ganze nun, in dem man ITv3 nicht auf die Whitelist setzt

Kann man die IT-V3 Signale denn sozusagen "rausfiltern" und eben nicht an das IT-Modul übergeben lassen?
Oder wie könnte man sie im Signalduino "Blacklisten"?

Zitat...oder mir jemand hilft das ITV3 Protokoll zu implementieren...
Ich selbst habe leider kein ITv3 Gerät...

Ich verwende einen IT-V3-Dimmer mit einem 433er-nanoCul (geflasht mit der a-CulFW)
http://forum.fhem.de/index.php/topic,35064.0.html
Das Protokoll ist sehr gut implementiert und ich kann z.B. im Gegensatz zum IT-V1 die einzelnen Dimmstufen direkt ansteuern.
Der Funktionsumfang der Befehle entspricht in etwa den FS20-Dimmern und ich habe damit auch ein WakeUp-Licht realisiert...
Vielleicht kann man sich beim Code der a-CulFW "bedienen" oder darauf aufbauen?

Wenn Du möchtest, könnte ich Dir ein Set zum erforschen spenden?
(Natürlich ohne jegliche Verpflichtung oder Garantien Deinerseits...)
Das wäre zum Beispiel ein IT-V3 Dimmer mit IT-V3 Fernbedienung:
http://www.amazon.de/Intertechno-Funksteckdose--300L-Funk-Zwischenstecker-Dimmer/dp/B00556KXZ6/ref=sr_1_1?ie=UTF8&qid=1452426878&sr=8-1&keywords=IT-300L
Bräuchte nur die Adresse für den Versand...

LG,
Mario

Ralf9 · 10 Januar 2016, 13:46:24

Zitat von: Hardlife am 10 Januar 2016, 13:16:31
Ich verwende einen IT-V3-Dimmer mit einem 433er-nanoCul (geflasht mit der a-CulFW)
http://forum.fhem.de/index.php/topic,35064.0.html
Das Protokoll ist sehr gut implementiert und ich kann z.B. im Gegensatz zum IT-V1 die einzelnen Dimmstufen direkt ansteuern.
Der Funktionsumfang der Befehle entspricht in etwa den FS20-Dimmern und ich habe damit auch ein WakeUp-Licht realisiert...
Vielleicht kann man sich beim Code der a-CulFW "bedienen" oder darauf aufbauen?

Der a-CulFW müsste doch auch das 10_IT.pm Modul verwenden. Ich würde dann im 10_IT.pm Modul einige Log Ausgaben anpassen, damit sie aussagekräftiger werden. Wenn Du dann mit diesem angepassten 10_IT.pm den Cul und den Signalduino parallel betreiben würdest, müsste man im log doch die Unterschiede sehen.

Gruß Ralf

Hardlife · 10 Januar 2016, 14:12:22

Hi Ralf!

Werden denn dann von beiden Sticks die Signale an FHEM weitergeleitet, oder "verwirft" FHEM bei doppelter Meldung eines der beiden?

Ich frage deshalb, weil ich mit dem SignalDuino gestern ja das Device:

Code Auswählen

DDDD0DDD010D1DD0DDD010D1DD0DD01 not defined (Address: DDDD0DDD010D1DD0DDD010D1DD Group: 0 Unit: DD01 Switch code: D)
und

Code Auswählen

DDD0D10010D1D0D10010D1D0D101D not defined (Address: DDD0D10010D1D0D10010D1D0D1 Group: 0 Unit: 1D Switch code: 0)
im Log hatte.

Jetzt, da ich FHEM wieder ohne Signalduino betreibe, taucht sporadisch (irgendein Nachbar wird das wohl im Einsatz haben) diese Gerät auf:

Code Auswählen

22:46:54 2: 0100101001110010101011011000000 not defined (Address: 01001010011100101010110110 Group: 0 Unit: 0000 Switch code: 0)

Gestern (Parallel-Betrieb von nanoCUL und Signalduino) hatte ich das korrekte "0100101001110010101011011000000"-Device aber nicht im Log...

Also nur immer eine der beiden Varianten?

Ich könnte versuchen, mit meinem nanoCUL einen korrekten IT-V3-Code zu senden, den mit dem Signalduino zu empfangen und die Log-Ausgabe des angepassten IT-Moduls aufzuzeichnen...

Ralf9 · 10 Januar 2016, 15:34:11

Zitat von: Hardlife am 10 Januar 2016, 14:12:22
Werden denn dann von beiden Sticks die Signale an FHEM weitergeleitet, oder "verwirft" FHEM bei doppelter Meldung eines der beiden?
Gestern (Parallel-Betrieb von nanoCUL und Signalduino) hatte ich das korrekte "0100101001110010101011011000000"-Device aber nicht im Log...
Also nur immer eine der beiden Varianten?

Hallo Mario,

in der Anlage ist die angepasste 10_IT.pm.
Eigentlich dürfte fhem nichts verwerfen. Falls ein Parallel-Betrieb von nanoCUL und Signalduino nicht funktioniert, kannst Du es ja mit dem selben Tastendruck nacheinander mit nanoCUL und Signalduino versuchen.
Hast Du beim cul den verbose auch auf 4?

Wenn ich es bei mir simuliere sieht es so aus:

Code Auswählen


2016.01.10 17:06:02 4: SIGNALduino/msg get raw: MS;P0=-10773;P1=-4628;P2=350;P3=-1039;P4=1045;P5=-346;D=21023454523232345232345232345454523454523234523234520234545232323452323452323454545234545232345232345202345452323234523234523234545452345452323452323452023454523232345232345232345454523454520;CP=2;SP=1;O;
2016.01.10 17:06:02 4: Founded matched MS Protocol id 3 -> itv1
2016.01.10 17:06:02 4: Decoded matched MS Protocol id 3 dmsg i0C49D92C49D92C49D8 length 72
2016.01.10 17:06:02 4: sduinoD IT: message "i0C49D92C49D92C49D8" (19)
2016.01.10 17:06:02 4: sduinoD ITv3dimm: bin message "000011000100100111011001001011000100100111011001001011000100100111011000" (72)
2016.01.10 17:06:02 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/10_IT.pm line 673.
2016.01.10 17:06:02 4: sduinoD IT: msgcode "DDD0D10010D1D0D10010D1D0D1001D" (30)
2016.01.10 17:06:02 1: PERL WARNING: substr outside of string at ./FHEM/10_IT.pm line 690.
2016.01.10 17:06:02 2: sduinoD IT: DDD0D10010D1D0D10010D1D0D101D not defined (Address: DDD0D10010D1D0D10010D1D0D1 Group: 0 Unit: 1D Switch code: 0)
2016.01.10 17:06:02 2: autocreate: define IT_DDD0D10010D1D0D10010D1D0D101D IT DDD0D10010D1D0D10010D1D0D1 0 1D
2016.01.10 17:06:02 1: define IT_DDD0D10010D1D0D10010D1D0D101D IT DDD0D10010D1D0D10010D1D0D1 0 1D: Define IT_DDD0D10010D1D0D10010D1D0D101D: wrong ITv3-Code format: specify a 26 digits 0/1 
2016.01.10 17:06:02 1: ERROR: Define IT_DDD0D10010D1D0D10010D1D0D101D: wrong ITv3-Code format: specify a 26 digits 0/1

Nachtrag:
Neue Version, nun werden auch die bin message und der msgcode ausgegeben.

Gruß Ralf

Sidey · 10 Januar 2016, 16:45:40

Hi Mario,

man kann über das Attribut whitelistID festlegen, welche Protokolle verarbeitet werden.

Dort müsstest Du die IDs für das eintragen, was Du verarbeiten möchtest...

In der CUL FW habe ich schon mal geschaut. Ich habe auch Björn dazu befragt.
So 100% klar ist mir das ganze nicht geworden.
Ich vermute, in der CUL FW werden zwei Signalpulse in ein Bit umgerechnet.
Das IT Modul rechnet aus diesen Bits dann ein Tristate oder sonstwas aus.
Die Umrechnung in DDD... passiert auf jeden Fall im IT Modul.

Ich habe bis heute nicht verstanden, warum das so gemacht wird.
Bei dem IT V3 Protokoll wird ein Bit (meinen Erkenntnissen) nach, mit vier Signalpegel dargestellt.
Ein Umrechnen in Tristate oder sowas wäre somit hinfällig.

Naja, wenn Du mir so ein Set zur Verfügung stellen möchtest, dann schicke ich dir meine Adresse in einer PM.

Ansonsten könntest Du auch mal den Verbose Level hoch setzen und eine Taste auf deiner FB drücken.
Vielleicht kriegen wir es auch so hin.

Grüße Sidey

pejonp · 10 Januar 2016, 17:04:39

Hallo Sidey,

ich habe seit einiger Zeit einen Signalduino + Empfänger RX868SH-DV mit einem esp8266 (WLan) aufgebaut. Ist für die WS-0101 und WS/WH1080. Es funktioniert besser als der direckte Anschluß per USB. (http://www.hjgode.de/wp/2015/11/05/fhem-serielle-gerat-uber-wifi-anbinden/)
Die Firmware ist 3.2.0-b10 SIGNALduino. Diese Kombination steht jetzt näher am Sender der Wetterstation, aber trotzdem ist der Empfang schlechter. Ich vermute seit der Version 3.2.0-b09. Das mitgelieferte Display (Wetterempfänger) ist weiter weg und empfängt besser.
Kann natürlich aus sein das das WLAn-Modul (esp8266) da etwas beeinflußt. Weiß ich nicht ;-(
Aber auch als ich den Empfänger RX868SH-DV am Signalduino per USB am Raspberry Pi hatte (Firmware 3.2.0-b10) war der Empfang anders. Es wurden Übertragungen ausgelassen. Am Display wurden aber andere Werte angezeigt oder haben sich schneller geändert. Beide Empfänger standen da noch nebeneinander.
Vielleicht weißt du was ich noch testen kann. Danke.

Jörg

Hauswart · 10 Januar 2016, 18:35:47

Zitat von: Hardlife am 09 Januar 2016, 13:51:19und die Flamingo FA21RF einbinden.

Darf ich blöd nachfragen wie genau du sie eingebunden hast? DOIF?

Hardlife · 10 Januar 2016, 20:40:30

Hallo Hauswart!

Ja, per DOIF.

Die Methode wird hier beschrieben und ist mit Statusanzeige/SMS/Pushmassage/Mail beliebig erweiterbar...
http://forum.fhem.de/index.php/topic,30125.msg359889.html#msg359889

Die Rauchmelder kann man mit RAW-Massages auch aus der Ferne auslösen...
Wird hier beschrieben:
http://forum.fhem.de/index.php/topic,30125.msg361027.html#msg361027

Man nimmt einfach den Code aus Schritt "3.) Rauchmelder auslösen"
...und schickt den extrahierten Code per "set sduino raw SR;;R=6;; UNDSOWEITER..." an der Rauchmelder...

Hardlife · 10 Januar 2016, 20:49:19

@Sidey!

Danke für den Tipp mit dem:
attr sduino whitelist_IDs

Nun, da ich alle Protokolle bis auf die benötigten deaktiviert habe, läuft alles fehlerfrei...

Bitte schick mir doch eine PN mit Deinen Daten, ich lasse Dir dann das Set zukommen.
(Als Dank für Dein tolles Produkt, die Unterstützung Deinerseits und eventuell kann man dann ja zukünftig das IT-V3-Protokoll integrieren...)

LG aus Österreich,
Hardlife

Kuzl · 11 Januar 2016, 07:39:31

Hallo Zusammen,

da sich der Arduino Pro Mini 3.3V/8MHz und 5V/16MHz nur im Spannungsregler und Quarz unterscheiden, hab ich in meiner Schaltung einfach den 3.3V durch einen 5V getauscht und mit 3.3V versorgt. Nun kann man auch wieder ohne Pegelwandler arbeiten und kann die vorhandene Firmware benutzen.
Meinen Wunsch nach einer 8MHz-Firmware ziehe ich daher zurück

Bis jetzt funktioniert alles wunderbar, bis auf merkwürdige "r0"-Meldungen im Log, aber da melde ich mich mal wan anders

ist allerdings schon immer drin, nicht erst seit dem neuen Arduino.

viele Grüße,
Kuzl

Sidey · 11 Januar 2016, 08:37:14

Zitat von: pejonp am 10 Januar 2016, 17:04:39
Hallo Sidey,

ich habe seit einiger Zeit einen Signalduino + Empfänger RX868SH-DV mit einem esp8266 (WLan) aufgebaut. Ist für die WS-0101 und WS/WH1080. Es funktioniert besser als der direckte Anschluß per USB. (http://www.hjgode.de/wp/2015/11/05/fhem-serielle-gerat-uber-wifi-anbinden/)
Die Firmware ist 3.2.0-b10 SIGNALduino. Diese Kombination steht jetzt näher am Sender der Wetterstation, aber trotzdem ist der Empfang schlechter. Ich vermute seit der Version 3.2.0-b09. Das mitgelieferte Display (Wetterempfänger) ist weiter weg und empfängt besser.

Hallo Jörg,

im CTW600 Thread wurde darüber auch schon mal berichtet.

Kannst Du zu Testzwecken mal den Manchester Decoder deaktivieren und berichten, ob es dadurch besser wird?

Kennst Du den Intervall, in dem die Station sendet?
Wenn ja, dann könntest Du auch noch mal mit Verbose 4 ein paar Minuten loggen.
Vielleicht wird das Signal ja gut empfangen, aber aufgrund zu knapper Toleranzen nicht ausgewertet.

Grüße Sidey