Signalduino Entwicklung

[carxperience1]

Hallo Sidney,

zunächst großes Kompliment für die bisherige Entwicklung.
Habe mehrere Bewegungsmelder mit HTE Chipsatz im Einsatz.

Folgende MU-Werte werden ausgegeben.

MU;P0=-264;P1=316;P2=-533;P3=585;P4=-9897;
D=001212121032121212103030341212121210321212121030303412121212103212121210303034121212121032121212103030341212121210321212121030303412121212103212121210303034121212121032121212103030341212121210321212121030303412121212103212121210303034121210;CP=1;O;
MU;P0=-555;P1=295;P2=-279;P3=560;P4=-9921;
D=010123010101012323234101010101230101010123232341010101012301010101232323410101010123010101012323234101010101230101010123232341010101012301010101232323410101010123010101012323234101010101230101010123232341010101012301010101232323410101010120;CP=1;O;
MU;P0=569;P1=-560;P2=290;P3=-278;P4=-9925;
D=012121212303030421212121230121212123030304212121212301212121230303042121212123012121212303030421212121230121212123030304212121212301212121230303042121212123012121212303030421212121230121212123030304212121212301212121230303042121212123012120;CP=2;O;
MU;P0=-569;P1=281;P2=-282;P3=571;P4=-9926;
D=010123232341010101012301010101232323410101010123010101012323234101010101230101010123232341010101012301010101232323410101010123010101012323234101010101230101010123232341010101012301010101232323410101010123010101012323234101010101230101010120;CP=1;O;

Hab leider (noch) keinen Durchblick wie ich sie in Fhem auswerten kann. Für jeden Tipp dankbar.

Gruß

[Ralf9]

Ich habe bei mir die Entfernung des 2. 75 eingebaut.
Die whitelist habe schonmal beim MS_Parse eingebaut.
Ich werde diese beide Änderungen ins dev-cresta einchecken.

So, jetzt ist es mir gelungen meine Änderungen sauber ins dev-cresta einzuchecken.
In der 00_SIGNALduino.pm war ein Durcheinander mit unix und Windows Zeilenenden. Damit kam mein unix Editor Kwrite und das diff nicht zurecht.
Jetzt haben alle Zeilen ein unix Zeilenende.
Bitte ab sofort nur noch änderungen mit unix Zeilenende einchecken, damit es auch so sauber bleibt.

Sidey, könntest Du bitte die Änderungen im dev-rawin in die dev-cresta übernehmen.

Gruß

[Sidey]

Hallo carexperience,

Bezogen auf die 1. Logzeile nehme ich an, dass die Nachricht zwischen der Folge 34 steht.

Ob 34 nun das Ende einer Nachricht oder der Anfang kann ich noch nicht sagen.
Die Werte dazwischen müssten wir nur noch hinsichtlich ihrer Bedeutung zuordnen. Sieht fast wie ein Tristate Format aus.

Was für Infos hast Du noch zu dem Melder? HTE Chipsatz sagt mir erst mal noch nichts.

Sidey

[Sidey]

Hi Ralf,

Danke für die Änderungen.
Ich schaue mir jetzt die commits an. Da sind aber noch Fehler enthalten...

Sidey, könntest Du bitte die Änderungen im dev-rawin in die dev-cresta übernehmen.

In welche richtung? dev-rawin -> dev-cresta oder  dev-cresta wieder zurück in dev-rawin ?

Sidey

[Ralf9]

Ich schaue mir jetzt die commits an. Da sind aber noch Fehler enthalten...

Welche Fehler? Ich habe die Änderungen bei mir getestet, sie funktionieren problemlos.

In welche richtung? dev-rawin -> dev-cresta oder  dev-cresta wieder zurück in dev-rawin ?

In der dev-rawin  haben die Zeilen der 00_SIGNALduino.pm momentan ein Windows Zeilenende, das finde ich nicht so gut.
In der dev-cresta haben alle Zeilen der 00_SIGNALduino.pm jetzt ein unix Zeilenende, deshalb wäre mir "dev-rawin -> dev-cresta" lieber

Gruß Ralf

[Sidey]

Welche Fehler? Ich habe die Änderungen bei mir getestet, sie funktionieren problemlos.

Das Präfix Hi, der Returnwert aus dem 14_Hideki ist gesetzt auch wenn nicht dekodiert werden konnte.
Habe jetzt einiges angepasst.

In der dev-rawin  haben die Zeilen der 00_SIGNALduino.pm momentan ein Windows Zeilenende, das finde ich nicht so gut.
In der dev-cresta haben alle Zeilen der 00_SIGNALduino.pm jetzt ein unix Zeilenende, deshalb wäre mir "dev-rawin -> dev-cresta" lieber

Ich glaube, dann sollte ich die Änderungen aus dev-cresta in dev-rawIn überführen und wir entfernen den dev-cresta Zweig.
Für heute wird mir das aber zu viel.
Ich hab jetzt etliches angepasst. Bestimmt geht irgendwo auch was nicht.   Heute komme ich nicht mehr zum Testen.

Grüße Sidey

[Ralf9]

Ich glaube, dann sollte ich die Änderungen aus dev-cresta in dev-rawIn überführen und wir entfernen den dev-cresta Zweig.

Mir wäre es lieber, wenn die dev-rawIn bleiben könnte bis die dev-cresta fertig und getestet ist.
Ich habe mir mal bei der 00_SIGNALduino.pm das diff zwischen dev-rawIn und dev-cresta angeschaut.
Die Änderungen die in die dev-cresta eingecheckt werden müssen sind überschaubar. Es reichen ein paar commits.
Es sind im wesentlichen die neueren Protokolle und die MU_Parse Routine.

Die dev-cresta kann dann direkt in die master.

Ich habe gesehen, daß Du recht fleißig warst und das ID7-Modul schon umbenannt hast. Könntest Du die 14_SD_WS07.pm in die dev-cresta kopieren, dann kann ich auch besser testen.

Gruß Ralf

[RappaSan]

Welche Version wird denn momentan zum flashen empfohlen?
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-cresta/controls_signalduino.txt

oder doch die aus dem Wiki
https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-rawIn/controls_signalduino.txt

[Sidey]

Mir wäre es lieber, wenn die dev-rawIn bleiben könnte bis die dev-cresta fertig und getestet ist.

Ja, das ist machbar. dev-rawIn verschwindet ja nicht, wenn wir dev-cresta auflösen.

Ich habe mir mal bei der 00_SIGNALduino.pm das diff zwischen dev-rawIn und dev-cresta angeschaut.
Die Änderungen die in die dev-cresta eingecheckt werden müssen sind überschaubar. Es reichen ein paar commits.
Es sind im wesentlichen die neueren Protokolle und die MU_Parse Routine.

Ja, ich habe immer mal den dev-cresta mit den Anpassungen aus dev-rawin aktualisiert. Deshalb ist er nicht so weit weg.
"dev-cresta branch is 94 commits ahead, 19 commits behind dev-rawIn"

Sobald die Aufgaben abgeschlossen sind, können wir im git es zusammenführen:
https://github.com/RFD-FHEM/RFFHEM/issues/33

Die dev-cresta kann dann direkt in die master.

Das klappt so noch nicht.
Ich würde jetzt so vorgehen:   1. dev-cresta wieder zurück in dev-rawin überführen.
Dann folgendes abarbeiten (durch das Zusammenführen wir schon einiges erledigt):
https://github.com/RFD-FHEM/RFFHEM/issues/31

Dann den Zweig rawIn nach Master überführen.

Ich habe gesehen, daß Du recht fleißig warst und das ID7-Modul schon umbenannt hast. Könntest Du die 14_SD_WS07.pm in die dev-cresta kopieren, dann kann ich auch besser testen.

Ich verstehe dein Problem, aber das wird mir zu viel kuddel muddel. Theroretisch ist es möglich den Zweig proto7 mit den Änderungen aus cresta zu aktualisieren, aber das gibt mir zu viel durcheinander.
Wenn dev-cresta in dev-rawIn überführt wurde, können wir dev-proto7 wieder an dev-rawin angleichen.
Natürlich könnten wir auch einfach das dev-proto7 un dev-rawin überführen, sobald
https://github.com/RFD-FHEM/RFFHEM/issues/32
abgeschlossen ist.

Da insgesamt nicht mehr viel zu erledigen ist, würde ich erst mal schnellstmöglich alles Richtung rawIn bringen.
Überwiegend ist es ja nur die commandref und ein bis zwei Kleinigkeiten. Kannst Du was davon übernehmen?

Grüße Sven

[Sidey]

Hi RappaSan,

die aus dem Wiki. Außer du hast einen Sensor der das Hideki Protokoll verwendet, dann den anderen. Wir sind aber dran, das ganze wieder zusammen zu führen.

https://raw.githubusercontent.com/RFD-FHEM/RFFHEM/dev-rawIn/controls_signalduino.txt

Grüße Sidey

[Ralf9]

Ich würde jetzt so vorgehen:   1. dev-cresta wieder zurück in dev-rawin überführen.
Dann folgendes abarbeiten (durch das Zusammenführen wir schon einiges erledigt):
https://github.com/RFD-FHEM/RFFHEM/issues/31

Ich wäre so vorgegangen:
1. die version im dev-cresta fertig entwickeln und testen. Während dieser Zeit die aktuelle funktionierende Version im dev-rawin lasen.
2. im dev-rawin die 00_SIGNALduino.pm mit den falschen Zeilenenden (Windows) löschen
3. die 00_SIGNALduino.pm vom dev-cresta ins dev-rawin kopieren.

Ich habe bedenken ob das Zusammenführen von dev-cresta nach dev-rawin problemlos klappt,
da die 00_SIGNALduino.pm im dev-rawin Windows Zeilenenden hat und im dev-cresta korrekte unix Zeilenenden.
Wie ich schon bemerkt habe, kommt das diff damit nicht zurecht.
Wenn Du dabei aber keine Probleme siehst, kannst Du es gerne probieren

Überwiegend ist es ja nur die commandref und ein bis zwei Kleinigkeiten. Kannst Du was davon übernehmen?

Meinst Du mit commandref die Device specific help? die hat bei mir beim sduino noch nie funktioniert. Funktioniert sie bei Dir?

Was meinst Du mit ein bis zwei Kleinigkeiten?

Hast Du inzwischen die Änderungen und Ergänzungen schon getestet?

Gruß Ralf

[hjgode]

Hi

also bei mir geht gerade nix mehr mir Hideki. Außerdem ist jetzt wohl wieder RF_Receiver 3.1.5 drin wenn man ein update force auf dev-cresta macht.

2015.10.12 19:33:37 4: SIGNALduino/msg READ: ^BMC;LL=-1042;LH=909;SL=-566;SH=416;D=AE5E174A4C37E8D16A0C2800;C=441;^C
2015.10.12 19:33:37 5: protocol does not match return from method: (message is to long)
2015.10.12 19:33:37 5: protocol does not match return from method: ()

~josef

[Sidey]

Das mit der Version überrascht  mich jetzt, das mit der Länge ist leicht zu lösen immerhin fängt es mit 0x75 an.

[hjgode]

Ich denke mal ich warte ab bis ihr mit dem Umbau fertig seid. Ein Restore läuft bei mir vorerst wieder.

~Josef

[Sidey]

Ich wäre so vorgegangen:
1. die version im dev-cresta fertig entwickeln und testen. Während dieser Zeit die aktuelle funktionierende Version im dev-rawin lasen.

Naja, wir haben jetzt Änderungen in dev-cresta die damit eigentlich nichts zu tun haben.
Funktionieren sollten die Änderungen in dev-cresta bevor wir zusammenführen.

Viel kann da nicht im argen sein.

2. im dev-rawin die 00_SIGNALduino.pm mit den falschen Zeilenenden (Windows) löschen
3. die 00_SIGNALduino.pm vom dev-cresta ins dev-rawin kopieren.

Da werfen ja die refs nicht übernommen bei Datei kopieraktionen. Zum Zusammenführen gibt es ja merge.
Das wird auch funktionieren.
Bezüglich Zeilenende kann ich ja prüfen und dann passend commiten.
Das mit dem merge mache ich schon.

Meinst Du mit commandref die Device specific help? die hat bei mir beim sduino noch nie funktioniert. Funktioniert sie bei Dir?

Ja die meine ich. Für signalduino geht die auch. Für Hideki und SD_WS_07 ist die noch zu finalisieren.
Zu einem Modul gehört das dazu.

Was meinst Du mit ein bis zwei Kleinigkeiten?

SCHAU doch mal in die verlinkten Issues auf Github. Es ist die commandref und der präfix für die dispatchte Nachricht.

Getestet habe ich bislang nur die whitelist. Das geht jetzt.
Mit osv2 bin ich nicht sicher,  ob unsere Langen Prüfung jetzt richtig funktioniert.
Hideki und proto7 konnte ich nicht testen.

Sidey