Signalduino Entwicklung

[hjgode]

Tia, schwierig. Deine Station wird vermutlich keinen Sender haben. Bleiben also die Sensoren.

Werden die Temperaturen dieser Sensoren denn in der Station angezeigt?

Nach meinen Recherchen empfängt die Station das Hideki Protokoll. Also senden Wind und Regenmesser mit diesem Protokoll.

Suche in deinem Log doch bitte mal nach folgenden Meldungen:

Code Auswählen Erweitern

crc failed
decrypt failed
Sensor Typ ...... not supported, please report sensor information!

Achso, welche Version des SIGNALduino setzt Du ein?

Grüße Sidey

Korrekt, das Hideki Modul 'kennt' derzeit nur die Tepm/Humi Typen. Für Wind und Regen müsste man das Modul noch ergänzen. Dazu bräuchten wir auch Testdaten.

~Josef

[noxx]

Was braucht ihr denn genau, oder kann ich das ggf selbst entschlüsseln?


Gesendet von meinem GT-I9195 mit Tapatalk

[noxx]

Vielleicht hilft euch oder mit das
http://members.upc.nl/m.beukelaar/Crestaprotocol.pdf

Gesendet von meinem GT-I9195 mit Tapatalk

[Ralf9]

ich habe die Firmware 3.2.0-b11 in den dev-32 Zweig geladen.

Es gibt ein paar Änderungen, die sich bei mir sehr positiv ausgewirkt haben:

1. Ich habe auf eine andere Entwicklungsumgebung umgestellt. Die Firmware wird nun mit neuen toolchains und librarys compiliert.
Durch den Einsatz aktuellere Librarys, sind (hoffentlich) auch weniger Fehler enthalten.

Wieviele Bytes werden damit im Flash belegt?

Welche toolchains und library Versionen verwendest Du?

Bei mir sind die folgenden Versionen installiert, sind diese einigermaßen aktuell?
cross-avr-gcc 4.8.3
cross-avr-binutils 2.23.2
avr-libc 1.8.1

Ich verwende zwar noch die etwas ältere Arduino IDE 1.0.6, diese müsste aber eigentlich auch die obrigen avr Versionen verwenden.

Gruß Ralf

[Sidey]

Hi,

ich habe es jetzt mit den Tools und den Libs aus der Arduino IDE1.6.x compiliert.

Aus meiner Erinnerung sind da ein paar Bugs im Zusammenhang mit delay und der Seriellen Anbindung korrigiert worden.

Derzeit werden ca. 18 KB Flash und 1100 Byte RAM belegt.

Einsparen können wir noch, wenn wir die Arduino String Lib durch Char Arrays ersetzen.
Das ist halt eine Fleiß Arbeit, da die reinkommenden Daten derzeit mit den Library Funktionen zerteilt werden. Geht aber auch mit Standard C Funktionen aus den avr Libs.

Ansonsten hat der Compiler schon eine Menge aus gebügelt.

Grüße Sidey

[Ralf9]

ich habe es jetzt mit den Tools und den Libs aus der Arduino IDE1.6.x compiliert.

Derzeit werden ca. 18 KB Flash und 1100 Byte RAM belegt.

Das hat einiges gebracht.
Das müsste für meine Ideen und Wünsche reichen.
Das freeram ist über 100 Byte mehr geworden.

Ich habe in der  SIGNALduino_ReadAnswer anpassungen vorgenommen. Damit müssten sich die Probleme mit dem get Befehl deutlich verringern.
Wenn vor der Antwort eine Signal Nachricht kommt, dann wird diese gelöscht.

Gruß Ralf

[Sidey]

habe einmal um .. den Manchester Decoder ausgeschaltet. Ich hoffe es sind jetzt brauchbare Daten dabei, wenn nicht sage einfach Bescheid.

Ja, ich habe anhand der Daten zwei Fehler in den FHEM Modulen gefunden und beheben können.
Ich habe jetzt erst mal aufgehört weiter zu suchen.

Bitte probiere es jetzt doch bitte mal aus und berichte, wie gut die Empfangsrate jetzt ist.
Grüße Sidey

[Sidey]

habe einmal um .. den Manchester Decoder ausgeschaltet. Ich hoffe es sind jetzt brauchbare Daten dabei, wenn nicht sage einfach Bescheid.

Ja, ich habe anhand der Daten zwei Fehler in den FHEM Modulen gefunden und beheben können.
Ich habe jetzt erst mal aufgehört weiter zu suchen.

Bitte probiere es jetzt doch bitte mal aus und berichte, wie gut die Empfangsrate jetzt ist.
Grüße Sidey

[Sidey]

Einschalten
....

Ausschalten:
.....

Schade, das was ich eingebaut habe, hat noch nicht gegriffen. Ich werde es aber mit den Daten von dir debuggen und weiter dran arbeiten.


Grüße Sidey

[Burny4600]

Habe heute bei dem Update gelesen das "DCF-77" herausgefiltert wurde.
Das wäre ja eigentlich eine tolle Sache die Raspis auf DCF-77 zu synchronisieren.

[Sidey]

Das hat einiges gebracht.

Was genau? Mein aufräumen oder die neuen Arduino Core Libs?
Bezüglich individueller Anpassungen könnte man noch virtuelle Funktionen wie
Custom_Setup
Custom_Loop
Custom_Command

Einbauen und zusätzlich eine custom.ino includieren.
Damit könnte man in einem eigenen Fork  sehr einfach Ergänzungen in der custom.ino implementieren und kann jederzeit recht gefahrlos den Rest aktualisieren.

Für die Ausgabe Serielle oder Ethernet müsste man sich noch etwas einfallen lassen und das Verarbeiten von eingehenden Kommandos würde ich gerne über eine Klasse realisieren.

Ich habe in der  SIGNALduino_ReadAnswer anpassungen vorgenommen. Damit müssten sich die Probleme mit dem get Befehl deutlich verringern.
Wenn vor der Antwort eine Signal Nachricht kommt, dann wird diese gelöscht.

Hi, ich hab es mir gestern angesehen.
Bist Du sicher, dass die Signalnachricht gelöscht wird? Den reinkommenden Datenstrom könnte man doch durch ein \r zerteilen... Das trennt Nachrichten derzeit voneinander.

Ansonsten ist das schon gut. Beim Testen habe ich gestern festgestellt, dass man Fhem scheinbar in eine Endlosschleife bekommen kann.
Das Szenario ist in etwa so.
Ich habe mit Get Raw eine Signal Nachricht gesendet.
Die wurde an _parse übergeben.
Parse hat undef zurück geliefert.

Ich habe das Problem noch nicht weiter untersucht.

Grüße Sidey

[GregPac]

Schade, das was ich eingebaut habe, hat noch nicht gegriffen. Ich werde es aber mit den Daten von dir debuggen und weiter dran arbeiten.


Grüße Sidey

Alles klar, vielen dank.

[pejonp]

....
Ansonsten ist das schon gut. Beim Testen habe ich gestern festgestellt, dass man Fhem scheinbar in eine Endlosschleife bekommen kann.
Das Szenario ist in etwa so.
Ich habe mit Get Raw eine Signal Nachricht gesendet.
Die wurde an _parse übergeben.
Parse hat undef zurück geliefert.
....
Grüße Sidey

Hallo Sidey,

ich habe heute ein Update beim Bannana PI gemacht und lande auch in einer Endlosschleife. CPU 110% perl.
Nach dem einspielen der Vorgängerversion vom signalduino.pm # $Id: 00_SIGNALduino.pm 72789 2016-01-05 10:10:10Z $, ist alles wieder ok.
Beim Signalduino.pm habe ich nur diese Änderungen gefunden, wahrschenlich sind es aber mehr :
Zeile 2127 / 2133:     if (@{$hash->{msIdList}} && $rmsg=~ m/^MS;(P\d=-?\d+;){3,6}D=\d+;CP=\d;SP=\d;/)

Auf meinem anderen Raspberry PI läuft es ohne Probleme: # $Id: 00_SIGNALduino.pm 72790 2016-01-15 19:00:00Z v3.2-dev$.

Wenn ich auf dem Bannana PI auch die Version vom # $Id: 00_SIGNALduino.pm 72790 2016-01-15 19:00:00Z v3.2-dev$ einspiele läuft es. Wie kann ich helfen, testen ?

Jörg

[pejonp]

Habe heute bei dem Update gelesen das "DCF-77" herausgefiltert wurde.
Das wäre ja eigentlich eine tolle Sache die Raspis auf DCF-77 zu synchronisieren.

Hallo Chris,

du solltest schon beim hochfahren deines Raspberry Pi oder anderen Servers die Zeit richtig setzten. ggf über NTP-Server (Network Time Protokoll). Im Nachgang stimmen dann die Zeiten im Log nicht oder wenn du etwas damit steuern möchtes sind falsche Zeiten auch sehr schlecht.

pejonp

[Ralf9]

Was genau? Mein aufräumen oder die neuen Arduino Core Libs?

Wahrscheinlich beides.

Bezüglich individueller Anpassungen könnte man noch virtuelle Funktionen wie
Custom_Setup
Custom_Loop
Custom_Command

Dies finde ich nicht so gut. Ich sehe da keine Vorteile. Damit wird es nur unnötig kompliziert und schwerer zu verstehen.
Zum verstehen der virtellen Sachen reichen meine Kenntnisse nicht aus.

und das Verarbeiten von eingehenden Kommandos würde ich gerne über eine Klasse realisieren.

Welche Vorteile hat dies?

Hi, ich hab es mir gestern angesehen.
Bist Du sicher, dass die Signalnachricht gelöscht wird? Den reinkommenden Datenstrom könnte man doch durch ein \r zerteilen... Das trennt Nachrichten derzeit voneinander.

Bei mir funktioniert es:

Code Auswählen Erweitern

2016.01.16 22:31:17 3: sduinoDo/RAW (ReadAnswerCut 123): MS;P0=500;P1=-1093;P2=-1948;P3=-3899;D=3101010202021020101010201010101020110202010101020202020101020202010202;CP=0;SP=3;O;
ITParams: 6 300
2016.01.16 22:31:17 3: sduinoDo/RAW (ReadAnswerCut): ITParams: 6 300
Cut

2016.01.17 15:10:02 3: sduino/RAW (ReadAnswerCut 98): P4=-3905;D=04020102010201010102010101010101010201020201010202020202020101020102020201;CP=0;SP=4;O;
OK
2016.01.17 15:10:02 3: sduino/RAW (ReadAnswerCut): OK
Cut

Ansonsten ist das schon gut. Beim Testen habe ich gestern festgestellt, dass man Fhem scheinbar in eine Endlosschleife bekommen kann.
Das Szenario ist in etwa so.
Ich habe mit Get Raw eine Signal Nachricht gesendet.
Die wurde an _parse übergeben.
Parse hat undef zurück geliefert.

Hast Du mir eine Raw Signal Nachricht bei der man eine Endlosschleife bekommen kann.
Mir ist es bis jetzt noch nicht gelungen in eine Endlosschleife zu kommen.

Gruß Ralf