Signalduino Entwicklung

RappaSan · 13 Mai 2016, 07:02:48

Im Moment verliere ich auch etwas die Übersicht über den Entwicklungsstand.
Der SOMFY-Zweig hat nichts mit dem momentanen dev-r32-Zweig zu tun, oder?
Denn sonst könnte ich's mir nicht erklären, daß es keinen zu interessieren scheint: Im neuesten dev-r32 klappt zumindest der IT-Sendezweig nicht mehr - zumindest der Teil, der für die IT/Elro-Steckdosen zuständig ist.

Nachtrag: Nach dem flashen des "fehlerhaften" dev-r32 hatte ich die Version V 3.2.0-b23 auf dem Signalduino.

Sidey · 13 Mai 2016, 09:00:27

Ist gerade alles etwas verworren. So gesehen gibt es keinen Somfy Zweig. Das ist vielleicht auch das Problem.

Es gibt Forks, diverse Pullrequests und Code im Forum.

Was ich versuche ist, die notwendigen Anpassungen in den devr32 Zweig zu übernehmen soweit das klar ist, was wo hin gehört.

Die Änderungsrate ist aber momentan doch recht hoch und es kommt zu Parallelen Entwicklungen.

Dass IT Senden im dev-r32 sollte eigentlich funktionieren.
Richtig ist aber leider, dass ich gestern eine Änderung gemacht habe, damit SOMFY Senden nicht mit IT Senden kollidiert.

Dadurch geht aktuell nur Senden für ITv1 Geräte und nicht für die anderen IT Geräte.
Ich werde den Teil korrigieren.

RappaSan · 13 Mai 2016, 09:01:50

Hallo Sidey,

Du hast es momentan nicht leicht

habeIchVergessen · 13 Mai 2016, 11:00:03

Zitat von: 1.fhemtester am 30 April 2016, 11:55:43
Beiliegende 14_SD_UT

Kannst du die o.g. Datei hier liefern?

Ellert · 13 Mai 2016, 16:53:00

@Sidey:

ZitatDer FHEMduino wird das Signal nicht richtig Auswerten, welches der SIGNALduino sendet. Allerdings sollten die Rolläden darauf reagieren.

Warum sollte er nicht?
Der FHEMduino empfängt auch meine Somfy Telis Handsender und legt Geräte dafür an, in Verbindung mit der 14_FHEMduino_SomfyR.pm.
Wenn der SIGNALduino Somfy Manchestercode sendet, dann müsste es der Rolladen und der FHEMduino gleichermassen empfangen.

habeIchVergessen · 13 Mai 2016, 17:14:37

@Ellert: zu dem Zeitpunkt war noch der Clock-Bug in dem von Sidey verwalteten Code. Also wurde eventuell etwas gesendet, aber nicht so, wie es sein muss.
Aktuell wird die Nachricht falsch negiert.

Ellert · 13 Mai 2016, 18:07:11

Zitat von: habeIchVergessen am 13 Mai 2016, 17:14:37
@Ellert: zu dem Zeitpunkt war noch der Clock-Bug in dem von Sidey verwalteten Code. Also wurde eventuell etwas gesendet, aber nicht so, wie es sein muss.
Aktuell wird die Nachricht falsch negiert.

Ja, das habe ich auch gerade festgestellt mit aktuellem Update aus dem dev-r23.

Zitat
2016.05.13 17:46:14 5: signal433/write: adding to queue sendMsg P43#A011000012389A#R6
2016.05.13 17:46:14 5: signal433: sendmsg Preparing manchester protocol=43, repeats=6, clock=660 data=5FEEFFFFEDB765, das B müsste C sein

zusätzlich müssten in 5FEEFFFFEDC765 die markierten Byte vertauscht werden, falls hier die tatsächlich gesendete Nachricht zu sehen ist.

habeIchVergessen · 13 Mai 2016, 18:31:50

in 00_SIGNALduino.pm muss

$data =~ tr/0123456789ABCDEF/FEDBCA9876543210/;

durch

$data =~ tr/0123456789ABCDEF/FEDCBA9876543210/;

ersetzt werden

A010000012389A müsste als 5F4F4F4FD5EDFF gesendet werden.

Kannst gern die hier testen:
https://github.com/habeIchVergessen/RFFHEM/raw/dev-r32/FHEM/00_SIGNALduino.pm
https://github.com/habeIchVergessen/Telegram-fhem/raw/master/Somfy/10_SOMFY.pm

Ellert · 13 Mai 2016, 20:24:49

ZitatKannst gern die hier testen:

Habe ich gemacht und mit dem Logikanalysator aufgezeichnet.

Einmal von nanoCul gesendet und einmal vom SDuino gesendet.

Zum SDuino gehört dieser Logauszug:

Zitat2016.05.13 20:14:39 5: signal433/write: adding to queue sendMsg P43#A0B0B0B02A1200#R6
2016.05.13 20:14:39 5: signal433: sendmsg Preparing manchester protocol=43, repeats=6, clock=660 data=5F4F4F4FD5EDFF
2016.05.13 20:14:39 4: signal433/set: sending via SendMsg: SM;R=6;C=660;D=5F4F4F4FD5EDFF
2016.05.13 20:14:39 5: signal433 SW: SM;R=6;C=660;D=5F4F4F4FD5EDFF
2016.05.13 20:14:39 5: signal433/HandleWriteQueue: nothing to send, stopping timer
2016.05.13 20:14:39 4: signal433/msg READ: SM;R=6;C=660;D=5F4F4F4FD5EDFF

Sidey · 13 Mai 2016, 20:36:04

Zitat von: Ellert am 13 Mai 2016, 16:53:00
@Sidey:Warum sollte er nicht?
Der FHEMduino empfängt auch meine Somfy Telis Handsender und legt Geräte dafür an, in Verbindung mit der 14_FHEMduino_SomfyR.pm.
Wenn der SIGNALduino Somfy Manchestercode sendet, dann müsste es der Rolladen und der FHEMduino gleichermassen empfangen.

Der Signalduino Sender Manchester, allerdings wartet der FHEMduino auf eine Preamble davor, die nicht zum Manchester Signal gehört. Die Preamble wird vermutlich gesendet, damit der Empfänger sein AGC einstellen kann.

Die Rolläden sollen diese Übertragung angeblich nicht Auswerten, was die Vermutung stützt, dass es nur für den Empfänger gemacht wird und nicht zur Nachricht gehört.

Der Signalduino sendet diese Preamble nicht. Könnte man einbauen, wenn man es muss, macht die Sache aber wieder ein kleines bisschen Aufwändiger. Da das Signal 6mal gesendet wird, kann sich der Empfänger bei der 1. Übertragung anpassen.

Wenn wir diese Preamble brauchen, würde ich es einbauen, ansonsten eher nicht um es einfach zu halten.

Grüße Sidey

Sidey · 13 Mai 2016, 20:46:46

Zitat von: hjgode am 12 Mai 2016, 22:18:13
Thema: SignalDuino stoppt:

weiss noch nict was da los ist. Hier mal mit verbose 5 und debug 1:

Um 21:33 die letzte Meldung und um 22:03 schlägt dann meine watchdog zu.

Seltsam,
es sieht so aus, als ob der Intervall überhaupt nicht gestartet wird.

Ich habe leider keinen SIGNALduino über IP angebunden.
Den Code habe ich durchgesehen. Die Prüfung, wird alle 5 Minuten durchgeführt. Allerdings sehe ich im Log keine Einträge, was seltsam ist.

Zum Reset noch eine Frage.
Das einzige, was Du resettest, ist doch die IP Verbindung. Den Arduino kannst Du ja so nicht resetten.
Mit Get uptime sollte sich das auch bestätigen lassen.

Grüße Sidey

Ellert · 13 Mai 2016, 21:01:36

Zitat von: Sidey am 13 Mai 2016, 20:36:04

Der Signalduino Sender Manchester, allerdings wartet der FHEMduino auf eine Preamble davor, die nicht zum Manchester Signal gehört. Die Preamble wird vermutlich gesendet, damit der Empfänger sein AGC einstellen kann.

Die Rolläden sollen diese Übertragung angeblich nicht Auswerten, was die Vermutung stützt, dass es nur für den Empfänger gemacht wird und nicht zur Nachricht gehört.

Der Signalduino sendet diese Preamble nicht. Könnte man einbauen, wenn man es muss, macht die Sache aber wieder ein kleines bisschen Aufwändiger. Da das Signal 6mal gesendet wird, kann sich der Empfänger bei der 1. Übertragung anpassen.

Wenn wir diese Preamble brauchen, würde ich es einbauen, ansonsten eher nicht um es einfach zu halten.

Grüße Sidey

Ich dachte nur, ich könnte den FHEMduino als Testempfänger nutzen. Das geht dann ja nicht. Danke für die Aufklärung.

habeIchVergessen · 13 Mai 2016, 21:03:52

reagiert das Rollo/stimmt das gesendete Signal?

viegener · 13 Mai 2016, 22:10:57

@habeIchVergessen: Habe mir gerade den Pullrequest angesehen. Generell sieht das gut aus, ich würde das auch übernehmen, allerdings möchte ich das ungerne direkt ins FHEM-SVN bringen, da ich nächste Woche in Urlaub gehe.

Eine Unterstützung für repetition gibt es jetzt noch nicht?

viegener · 13 Mai 2016, 22:31:13

@habeIchVergessen: Kommando zurück habe gerade den gemergten Code ausprobiert, leider geht bei mir jetzt nichts mehr, da muss ich jetzt erstmal schauen was schiefgeht