Signalduino Entwicklung

Ralf9 · 20 März 2016, 21:15:42

Zitat von: Sidey am 20 März 2016, 21:05:36
Mach das, nur was ist jetzt anders?

Da jetzt auch für das IT v1 die sendmsg verwendet wird, wird die in der Firmware interne v1 Senderoutine nicht mehr verwendet.
Dadurch wird jetzt auch die "set ITClock" und "get ITParms" nicht mehr benötigt.

Gruß Ralf

Ralf9 · 20 März 2016, 22:20:14

Ich habe die Anpassungen an der 00_SIGNALduino.pm commited.

hier sind auch die Anpassungen am IT-Modul:
https://github.com/Ralf9/test/blob/master/FHEM/10_IT.pm

Code Auswählen

update all https://raw.githubusercontent.com/Ralf9/test/master/controls_signalduino.txt

Gruß Ralf

Sidey · 20 März 2016, 22:53:43

Hi Ralf,

danke für die Unterstützung.

Vorweg, als Entwarnung kann ich sagen. Auch ohne die Anpassungen von Ralf hat ITv1 Senden funktioniert.
Ich hatte bei mir nur den Pin falsch verbunden....

Die Anpassungen am IT Modul habe ich mir angesehen. Habe gesehen Du hast die Implementierung Abhängig vom IO Device gemacht.
Du kannst den Patch ja mal vorschlagen, die richtigere Lösung denke ich aber wäre, wenn das CUL Modul auch IOWrite zur Verfügung stellt.
Dann müsste das IT Modul nicht unterscheiden, was es aufruft.

So, jetzt schau ich mir noch an, warum die Clock bei ITv3 fehlt.

Grüße Sidey

Sidey · 20 März 2016, 23:31:34

Hi Ernst,

vielen Dank für deinen Beitrag.

Zitat von: ernst1024 am 14 März 2016, 17:49:24
Jetzt kommt SIGNALduino ins Spiel. Ich habe also den Homecode an der Fernbedienung abgeändert und gescannt. Dann, der besseren Zuordnung halber umbenannt und schalte so über ein notify die entsprechende FSD. Das klappt auch gut. Nur erzeugt "set FSD3 $EVENT" wiederum einen neuen Eintrag, diesmal halt mit dem richtigen Homecode, der ja gesendet wird um die entsprechende FSD zu schalten. Und genau das würde ich gerne vermeiden. Gibt es da Hoffnung?

Ich muss leider gestehen, dass ich nicht ganz verstanden habe, wieso Du den homecode geändert hast.
Wieso schaltest Du die Steckdosen nicht einfach mit dem SIGNALduino? Dann dürfte es doch keinerlei Probleme geben.

Wenn Du nur einen zweiten Schalter wolltest, dann kannst Du das auch mit einem Dummy oder doif lösen.

Grüße Sidey

Sidey · 20 März 2016, 23:33:18

Zitat von: sash.sc am 19 März 2016, 10:39:47
Hätte es einen Vorteil den Signalduino als auch Sender einzusetzen, gegenüber den nano cul mir der afw?

Naja, das ist nicht so einfach zu beantworten denke ich.
Solange der CUL alles sendet was Du brauchst, dann ist es doch gut. Wenn Du ihn nur fürs senden hast, dann ist er vermutlich überflüssig.

Grüße Sidey

Lothar64 · 21 März 2016, 21:39:30

Hallo,
ich habe hier etliche Türkontakte und einen Bewegungsmelder, die ein Signal mit "unknown tristate" senden. Ich habe mal in Signalduino.pm die zwei auskommentierten log3 Ausgaben in SIGNALduino_Parse_MS einkommentiert. Dann sieht man folgende Ausgaben.

Code Auswählen


2016.03.20 22:11:20 4: sduino/msg READ: MS;P0=172;P1=-523;P2=512;P3=-204;P4=-5723;D=04010123230101230101232323230101010101010101012323;CP=0;SP=4;O;
2016.03.20 22:11:20 4: sduino: Matched MS Protocol id 3 -> itv1
2016.03.20 22:11:20 5: sduino: Starting demodulation at Position 2
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 01
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: demodulating 23
2016.03.20 22:11:20 5: sduino: postdemodulation value 0 0 1 1 0 0 1 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 1 1
2016.03.20 22:11:20 4: sduino: Decoded MS Protocol id 3 dmsg i327803 length 24
2016.03.20 22:11:20 5: sduino: converted Data to (i327803)
2016.03.20 22:11:20 5: sduino dispatch i327803
2016.03.20 22:11:20 4: message "i327803" (7)
2016.03.20 22:11:20 4: unknown tristate in "100111100000000011"

Wie man sieht wird der float Zustand genau anders rum gesendet, erst der breite Puls, dann der kurze. Das entspricht nicht der Beschreibung in dem PT2262 Datenblatt. Kann man das in der Signalduino.pm nicht auch als gültigen Puls "drehen", damit die anderen Module den Puls als float erkennen und verarbeiten können?
Die Module senden auch eine Pulsfolge, die 46ms lang ist. Ist die Beschränkung auf 31ms in dem Signalduino nötig? Ich habe das mal auf 62ms erhöht und kann dann noch weitere Sensoren sehen.

Vielen Dank für eure Hilfe
Lothar

mahowi · 22 März 2016, 08:17:56

Ich hab gerade das Update aus der dev32 gemacht und es wurde ja auch wieder die Firmware neu heruntergeladen. Ist es richtig, daß die sich gar nicht geändert hat? Ich habe vor und nach dem Flashen dieselbe Version:

Code Auswählen

V 3.2.0-b14 SIGNALduino - compiled at Mar 4 2016 22:13:07

Noch eine Kleinigkeit: bei "get cmds" wird die Fehlermeldung ("? Use on of") vom sduino nicht ausgefiltert:

Code Auswählen

?UseoneofViRtXFSPCG

RappaSan · 22 März 2016, 12:24:58

Läßt sich die Signalduino Software auf einen ESP8266 wie z.B. NodeMCU portieren?
Von der Rechenleistung und dem Flashspeicher sollte es doch gehen, oder?

Sidey · 22 März 2016, 14:19:50

Zitat von: RappaSan am 22 März 2016, 12:24:58
Läßt sich die Signalduino Software auf einen ESP8266 wie z.B. NodeMCU portieren?
Von der Rechenleistung und dem Flashspeicher sollte es doch gehen, oder?

Ich habe zwei auf dem Schreibtisch liegen, allerdings noch nicht ausgepackt.

Ich bin nicht sicher, was man so alles anpassen müsste.
Im großen und ganzen muss das gehen.
Wenn ich mal die Bugs beseitigt habe, würde ich mich dem widmen.

Naja, mal sehen. Vielleicht mache ich das auch früher, debuggen müsste mit der extra Power ja einfacher werden.
Bislang habe ich mich aber mit der Hardware noch nicht beschäftigt.

Grüße Sidey

RappaSan · 22 März 2016, 14:25:57

Ich habe mir vor geraumer Zeit beim Ali ein paar von den Dingern bestellt, um ESPEasy ausprobieren zu können. Dazu noch ein paar BME280 Sensoren. Klappt prima, seit dieser Zeit wird von dem Ding mit dem Sensor Temperatur, Luftfeuchtigkeit und Luftdruck gemessen und an den FHEM-Server gemeldet. Und das Ganze eben per WLAN.

Ralf9 · 22 März 2016, 20:53:49

Zitat von: Lothar64 am 21 März 2016, 21:39:30
Hallo,
ich habe hier etliche Türkontakte und einen Bewegungsmelder, die ein Signal mit "unknown tristate" senden. Ich habe mal in Signalduino.pm die zwei auskommentierten log3 Ausgaben in SIGNALduino_Parse_MS einkommentiert. Dann sieht man folgende Ausgaben.

Wie man sieht wird der float Zustand genau anders rum gesendet, erst der breite Puls, dann der kurze. Das entspricht nicht der Beschreibung in dem PT2262 Datenblatt. Kann man das in der Signalduino.pm nicht auch als gültigen Puls "drehen", damit die anderen Module den Puls als float erkennen und verarbeiten können?

Türkontakte und Bewegungsmelder

Code Auswählen

2016.03.22 19:14:57 4: sduinoD/msg get raw: MS;P0=172;P1=-523;P2=512;P3=-204;P4=-5723;D=04010123230101230101232323230101010101010101012323;CP=0;SP=4;O;
2016.03.22 19:14:57 4: sduinoD: Matched MS Protocol id 3 -> itv1
2016.03.22 19:14:57 5: sduinoD: Starting demodulation at Position 2
2016.03.22 19:14:57 4: sduinoD: Decoded MS Protocol id 3 dmsg i327803 length 24
2016.03.22 19:14:57 5: sduinoD: converted Data to (i327803)
2016.03.22 19:14:57 5: sduinoD dispatch i327803
2016.03.22 19:14:57 4: sduinoD IT: message "i327803" (7)
2016.03.22 19:14:57 4: sduinoD IT:unknown tristate in "100111100000000011"

ITv1 Sender

Code Auswählen

2016.03.22 19:22:22 4 : sduino/msg READ: MS;P0=-414;P1=1118;P2=-1096;P4=340;P5=-11191;D=45421042424242424242424242424242424242421042104210;CP=4;SP=5;O;
2016.03.22 19:22:22 4 : sduino: Matched MS Protocol id 3 -> itv1
2016.03.22 19:22:22 5 : sduino: Starting demodulation at Position 2
2016.03.22 19:22:22 4 : sduino: Decoded MS Protocol id 3 dmsg i400015 length 24
2016.03.22 19:22:22 5 : sduino: converted Data to (i400015)
2016.03.22 19:22:22 5 : sduino dispatch i400015
2016.03.22 19:22:22 4 : sduino IT: message "i400015" (7)
2016.03.22 19:22:22 4 : sduino IT: msgcode "F00000000FFF" (12)
2016.03.22 19:22:22 3 : sduino IT: IT_F00000000F_ITV1 off->on

Hallo Sidey,

gibt es einen besonderen Grund, warum die Protokol ID 3 und ID 17 einen clockabs von -1 haben?
Dadurch werden die ID 7 Temperatursensoren z.T. auch als ID 17 erkannt.
Mit einem clockabs von z.B. 300 bei der ID 3, würden die o.g. Türkontakte nicht mehr als ID 3 erkannt und man könnte dafür eine eigene Protokol ID anlegen.

Gruß Ralf

Ralf9 · 22 März 2016, 21:19:50

Zitat von: mahowi am 22 März 2016, 08:17:56
Ich hab gerade das Update aus der dev32 gemacht und es wurde ja auch wieder die Firmware neu heruntergeladen. Ist es richtig, daß die sich gar nicht geändert hat? Ich habe vor und nach dem Flashen dieselbe Version:
Code Auswählen Erweitern
V 3.2.0-b14 SIGNALduino - compiled at Mar 4 2016 22:13:07

Wenn beim update eine Datei neu heruntergeladen wird, bedeutet dies nicht immer, daß sich auch was geändert hat.
Z.Zt. ist die Firmware V 3.2.0-b12 zu empfehlen. Die neueren sind fehlerhaft.

Ich denke Sidey wird sich hier melden, wenn die Firmware, an der er gerade arbeitet, fertig ist.
https://forum.fhem.de/index.php/topic,43548.msg427788.html#msg427788

Gruß Ralf

Ralf9 · 22 März 2016, 21:29:01

Zitat von: Ralf9 am 20 März 2016, 22:20:14
Ich habe die Anpassungen an der 00_SIGNALduino.pm commited.

hier sind auch die Anpassungen am IT-Modul:
https://github.com/Ralf9/test/blob/master/FHEM/10_IT.pm

Code Auswählen Erweitern
update all https://raw.githubusercontent.com/Ralf9/test/master/controls_signalduino.txt

Nachtrag:
Das o.g. IT-Modul funktioniert z.Zt. nur mit der aktuellen dev-r32. Per default wird als Clock 250 verwendet. Bei Bedarf kann im IT-Modul für jedes Device getrennt die clock und die ITrepetition als Attribut festgelegt werden.

Gruß Ralf

Lothar64 · 22 März 2016, 22:37:39

Hallo,
es wäre schön, wenn ihr eine Lösung für mein Problem findet.

Zitat
Hallo Sidey,
gibt es einen besonderen Grund, warum die Protokol ID 3 und ID 17 einen clockabs von -1 haben?
Dadurch werden die ID 7 Temperatursensoren z.T. auch als ID 17 erkannt.
Mit einem clockabs von z.B. 300 bei der ID 3, würden die o.g. Türkontakte nicht mehr als ID 3 erkannt und man könnte dafür eine eigene Protokol ID anlegen.

Gruß Ralf

Wie wäre es, wenn man die gültigen tristate Zustände abprüft, so wie in 10_IT.pm. Dann kann man unabhängig vom der clock eine andere ID zuweisen.
Gruß
Lothar

Sidey · 22 März 2016, 23:49:30

[quote author=Ralf9 link=topic=38831.msg428651#msg428651
Hallo Sidey,

gibt es einen besonderen Grund, warum die Protokol ID 3 und ID 17 einen clockabs von -1 haben?
Dadurch werden die ID 7 Temperatursensoren z.T. auch als ID 17 erkannt.
Mit einem clockabs von z.B. 300 bei der ID 3, würden die o.g. Türkontakte nicht mehr als ID 3 erkannt und man könnte dafür eine eigene Protokol ID anlegen.
[/quote]

Bei -1 wird der Takt automatisch ermittelt.
Bei den vielen Steckdosen, gibt es leider keinen festen Takt.

Entweder man arbeitet mit einem variablen Takt (so wie jetzt) um all die verschiedenen Geräte zu unterstützen, oder wir müssten für jeden Takt ein eigenes Protokoll anlegen.

Denkbar wäre auch noch eine Range von z.B. 160 - 300. Kann aber auch sein, dass es ein Gerät gibt, welches dann 400 benötigt usw.

Grüße Sidey