Signalduino vs. Signalduino

[Ralf9]

Bei dem 00_SIGNALDuino Modul von Sidey würden schon kleine Änderungen bei den recht scharfen regex in den Parse Routinen ausreichen, damit auch die mit meiner firmware empfangenen raw-Nachrichten verarbeitet werden.

Bei den rexex werden z.Zt. auch am Ende der raw-Nachrichten Sachen geprüft, die zum Verarbeiten gar nicht benötigt werden:
- Bei den MS-Nachrichten braucht was hinter CP=.. und SP=.. kommt nicht geprüft werden
- Bei den MU-Nachrichten braucht was hinter D=.. kommt nicht geprüft werden
- Bei den MC-Nachrichten braucht was hinter C=.. und L=.. kommt nicht geprüft werden
- Bei den MN-Nachrichten braucht was hinter D=.. kommt nicht geprüft werden

Wenn das "get raw" wieder eingebaut würde, wäre das senden von raw-Befehlen wieder komfortabler.
Momentan ist es recht umständlich, wenn man die Rückmeldungen der firmware sehen will. Vor dem "set raw" muß man erst das sduino verbose auf 4 erhöhen damit man die Rückmeldungen im log sehen kann.

Bei MC-Nachrichten kann es Unterschiede geben, da es bei Manchester in der firmware und beim 00_Signalduino Modul unterschiede gibt.

Gruß Ralf 
 

[Sidey]

Hallo Sidey,
ich bin damals z.B. wegen der besseren Somfy-Unterstützung zur Version von Ralf gewechselt

Damals? Was genau ist da besser, kannst Du das näher beschreiben?

... Auch gefallen mir die Einstellungsmöglichkeiten bei seiner Version besser.

Welche Einstellmöglichkeiten fehlen deiner Ansicht nach dem SIGNALDuino?


Grüße Sidey

[Ralf9]

Kann ich dies auch mit dem github desktop machen?
https://dev.to/jmalvarez/how-to-cherry-pick-a-commit-from-another-repository-4pf1

Hat sich erledigt, das cherry pick geht mit github desktop recht komfortabel

[rob]

Mit dem Status Quo hatte ich nie wirklich Probleme. Für beide Varianten bekam ich stets super Unterstützung  . Hier stehen imho im Grunde zwei Ansagen im Raum: nicht beides gleichzeitig nutzbar und unnötige Probleme.

Für mich bleibt unklar, welche Probleme mit der Trennung konkret gelöst werden sollen. Was sind diese Probleme? Geht es allein um Doku? Gibt es evtl. andere/ bessere Lösungen als den Split?
Es gibt wohl keine Lösung ohne andere Nachteile. Und wenn unterm Strich nur "Probleme" mit neuen "Problemen" getauscht werden, war der Aufwand/ Wirbel schnell umsonst. Bsp: Wohin melde ich dann künftig neue Geräte/ Protokolle usw.?

Zu "nicht gleichzeitig nutzbar" fällt mir auf, dass einige Leute zwei oder mehr FHEM-Instanzen nutzen. Wenn ich partout mehrere S'Duinos mit inhaltlich versch. aber gleichlautenden Modulen haben muss, würde ich es damit versuchen.

Ralf, Du hast eh schon losgelegt. Wie würde sich der Übergang aus Deiner Sicht konkret für User darstellen?
Gedanke: Die betroffenen User müssten ja meist "https://raw.githubusercontent.com/Ralf9/RFFHEM/..." unter update list stehen haben. Ließe sich ggf. eine (einmalige??) Log-Meldung in FHEM generieren, wenn das der Fall ist + das neue Repo genommen werden muss, aber noch Devices vom Typ "SIGNALduino" vorhanden sind?
Bspw.: "The Repo for your SIGNALduino(s) is outdated, please change your update source to the new one. For further information read this: https://blablabla  ..."
Der Trigger wäre dann wohl update all(?).

Viele Grüße
rob

[Ralf9]

Ja die Trennung durch Umbenennung von meinem 00_SIGNALDuino Modul hat Vorteile und auch Nachteile. Es ist dann kein einfacher wechsel zwischen den 00_SIGNALDuino Modulen mehr möglich.

Ralf, Du hast eh schon losgelegt. Wie würde sich der Übergang aus Deiner Sicht konkret für User darstellen?

Für das neue umbenannte 00_SIGNALDuino Modul gibts dann ein neues repro
https://github.com/Ralf9/SIGNALduinoADV_FHEM
Dann muss man aktiv die Updatequelle umstellen und sollte daher dann auch wissen, dass man seine sduino Devices ändern muss.
In diesem repro ist dann auch meine Version des 14_SD_WS Moduls. Ich bin gerade dabei das 14_SD_WS Modul so anzupassen, daß es auch bei FSK mit dem 00_SIGNALDuino Modul von Sidey verwendet werden kann.

[Ralf9]

Ich habe nun das 00_SIGNALduino.pm in 00_SIGNALduinoAdv.pm umbenannt. Es war im Code recht viel umzubenennen. Ich habe es noch nicht komplett getestet.
Dadurch hat sich auch der TYPE in SIGNALduinoAdv geändert
z.B.

Code Auswählen Erweitern

define sduino SIGNALduinoAdv /dev/serial/by-id/usb...
versionmodul v3.5.1-ralf_...
versionprotoL v3.5.1-ralf_...

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/SIGNALduinoAdv_FHEM/master/controls_ralf9_signalduino.txt
https://github.com/Ralf9/SIGNALduinoAdv_FHEM/tree/master/FHEM
https://github.com/Ralf9/SIGNALduinoAdv_FHEM/commit/c47119b528fb59c89a83a2e8eddd6ea248efa95c

FSK funktioniert nur mit meiner Version des 14_SD_WS Moduls. Ich habe Anpassungen vorgenommen, damit es auch bei FSK mit dem 00_SIGNALduino Modul von Sidey funktioniert:

- dmsg mit den ID 117 werden nach 207 geändert und die ersten 4 Zeichen entfernt, damit es kompatibel zum Modul von Sidey ist
- ID 115: wenn die dmsg vom 00_SIGNALduino Modul von Sidey kommt, werden die ersten 4 Zeichen entfernt
- ID 211: nach ID 125 geändert damit es kompatibel zum Modul von Sidey ist
- ID 213: nach ID 126 geändert damit es kompatibel zum Modul von Sidey ist

Bei den folgenden Modulen sind für die 00_SIGNALduinoAdv.pm Anpassungen notwendig:
10_IT
14_CUL_TCM97001
10_SOMFY
Sind im SVN (FHEM update)

36_PCA301
https://github.com/Ralf9/36_PCA301.pm

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/Ralf9/36_PCA301.pm/master/controls_ralf9_36_PCA301.txt
10_KOPP_FC
Siehe Anlage

14_SD_Keeloq
todo

Gruß Ralf

[rob]

Hallo Ralf.

Vielen Dank für die Umstellung + Info. Hab es bei mir jetzt auch nachgezogen. Einfach per defmod geht es zwar nicht - löschen und neu anlegen ist aber auch kein Drama

Beste Grüße
rob

[weini]

Hallo Ralf!

Vielen Dank dir!

Ich habe die Umstellung vor einigen Tagen vollzogen und es läuft bisher alles problemlos.
Mein 868 MHz SignalDuino läuft jetzt mit dem Adv-Modul und deiner FW und mein 433 MHz SignalDuino mit der Standard-FW und dem "normalen" Modul.

Noch eine Frage: Da meine Zähler erneuert wurden und jetzt "funken" würde ich gerne WM-Bus Signale Empfangen. Charmant wäre, wenn ich das mit meinem 868 MHz SignalDuino machen könnte.

• Dafür braucht es ja die 4.2 FW, richtig? Gibt es die auch schon für den nanoC1011 SignalDuino oder nur für Maple/ESP?
• Falls ich das mit meinem nanoC1011 nutzen kann, dann würde ich alle 6h auf den WM-Bus Modus schalten und danach wieder zurück auf LaCrosse. Mache ich mir damit auf die Dauer das Flash-RAM kaputt oder sollte das funktionieren?

VG,
weini
[/list]

[Ralf9]

Hallo weini,

nein, beim Signalduino funktioniert WMBUS nur mit dem Maple und ESP32
Für den nanoC1011 gibts eine culw firmware
https://forum.fhem.de/index.php?topic=24517.msg915481#msg915481

Das optimierte wechseln der aktiven EEPROM Bank, bei dem nicht ins EEPROM (flash) geschrieben wird, funktioniert nicht beim WMBUS

Mit nachgestelltem f optimiertes wechseln der aktiven EEPROM Bank (nur bei FSK, ccmode 1-4, nur ab Firmware V3.3.5 und V4.2.2)

Gruß Ralf

[weini]

Vielen Dank dir für die schnelle Antwort.
Dann muss ich überlegen wie ich das anders baue. Ich hätte zwar noch einen 868 MHz CUL "übrig", aber keine freien USB Anschlüsse mehr am Raspi.
Also entweder noch mehr Kabelverhau mit einem Hub oder vielleicht doch ein Umstieg auf den Maple...

[elektron-bbs]

Da du Firmware und Module von Ralf9 verwendest, kann ich nicht direkt weiter helfen. Wahrscheinlich müsstest du mal ein Update durchführen. In der aktuellen Version von Ralf9 sehe ich den Inkbird.

Besprochen wurde das Protokoll hier: https://forum.fhem.de/index.php/topic,128945.0.html

[OliS.]

Sorry, ich hatte meinen Post gelöscht, bevor ich Deine Antwort gesehen habe. Ich hatte es in der Zwischenzeit mit Sideys Version und einer anderen Hardware probiert. Damit konnte ich den Sensor dann empfangen.
Leider reicht das Funksignal des Thermometers nicht bis in den Keller (wo mein Server steht). Deshalb werde ich mal schauen, ob ich mir einen SignalESP baue.

Lieben Dank trotzdem schon mal für die Unterstützung.
LG Oli

[Ralf9]

Nicht so ungeduldig, an einem Tag wie heute wo viele draußen unterwegs sind, kann es etwas länger dauern.
Im Sommer kann es bei schönen Wetter auch mal länger als einen Tag dauern bis eine Antwort kommt.

Ich habs mirs mal angeschaut.
In der Protokolliste sieht man bei der ID 123 "modulation=2-FSK"
https://ralf9.github.io/SD_Device_Proto.html

Standardmässig ist SlowRF (ASK/OOK) aktiv, bei xFSK muss ein anderer rfmode gewählt werden.
Bei Sideys Version wird der rfmode über ein Attribut gewählt.
Bei meiner Version mit "set sduino rfmode" oder "set sduino rfmodeTesting"
Bei dem Inkbird ist es rfmodeTesting, da noch rückmeldungen fehlen und es noch nicht zu Ende entwickelt wurde. Es kann noch sein, daß beim Batteriewechsel noch nicht alles passt.

Bei meiner Version sieht es so aus:

Code Auswählen Erweitern

set sduino rfmodeTesting Inkbird_433__B18_N14_FSKIm reading rfmode steht dann: "Inkbird_433__B18_N14_FSK => ok,N=14,ccmode=1"

Ein "get sduino ccconf" ergibt:

Code Auswählen Erweitern

ccconf: freq:433.920MHz bWidth:101KHz rAmpl:33dB sens:8dB (DataRate:9992.60Baud)
Modulation:2-FSK (SYNC_MODE:16/16 sync) DEVIATN:34.912kHz
Gruß Ralf

[OliS.]

Mit Ungeduld hatte das tatsächlich gar nichts zu tun. Ich hatte nur nach Lektüre der ganzen anderen Threads zu dem Thema das Gefühl, dass meine Frage in diesem Thread gar nicht richtig platziert gewesen ist. Als Neueinsteiger in Sachen SignalDuino ist braucht man etwas, um hinter die Unterschiede zwischen dem "offiziellen" Zweig und Deinem Fork zu kommen.
Ich erwarte hier wirklich von niemandem eine sofortige Antwort. Schon gar nicht, da ich als Nichtentwickler selbst ja kaum etwas beisteuern kann. Von daher weiß ich Eure Arbeit wirklich sehr zu schätzen.

Ich habe mich jetzt weiter eingelesen und mittlerweile empfange ich das Thermometer zuverlässig mit einem SignalESP. Die Reichweite ist allerdings immer noch unterirdisch, was aber vermutlich an dem ungeeigneten 868MHz Empfangsmodul liegt.

Lieben Dank noch mal für die Antworten.
Oli

[Ralf9]

Zum einen wirft mir FHEM das hier ins log:

Code Auswählen Erweitern

2024.06.20 11:46:13 1: PERL WARNING: Constant subroutine main::SDUINO_INIT_WAIT_XQ redefined at /usr/lib/x86_64-linux-gnu/perl-base/constant.pm line 171.
2024.06.20 11:46:13 1: PERL WARNING: Constant subroutine main::SDUINO_INIT_WAIT redefined at /usr/lib/x86_64-linux-gnu/perl-base/constant.pm line 171.
2024.06.20 11:46:13 1: PERL WARNING: Constant subroutine main::SDUINO_VERSION redefined at /usr/lib/x86_64-linux-gnu/perl-base/constant.pm line 171.
2024.06.20 11:46:13 1: PERL WARNING: Constant subroutine main::SDUINO_MC_DISPATCH_VERBOSE redefined at /usr/lib/x86_64-linux-gnu/perl-base/constant.pm line 171.
2024.06.20 11:46:13 1: PERL WARNING: Subroutine cartesian_product redefined at ./FHEM/00_SIGNALduinoAdv.pm line 2399.
2024.06.20 11:46:13 1: PERL WARNING: Subroutine SIGNALduino_filterMC redefined at ./FHEM/00_SIGNALduinoAdv.pm line 5649.
2024.06.20 11:46:13 1: PERL WARNING: Subroutine SIGNALduino_filterSign redefined at ./FHEM/00_SIGNALduinoAdv.pm line 6349.
2024.06.20 11:46:13 1: PERL WARNING: Subroutine SIGNALduino_compPattern redefined at ./FHEM/00_SIGNALduinoAdv.pm line 6422.Da scheint also die Trennung des namespace noch nicht abgeschlossen zu sein (Maple steht in der config weiter hinten, es werden also die neuen Funktionen genutzt), das ist der Startvorgang nach update all wie von Ralf gestern hier gepostet (der Schritt fehlt wohl noch im Wiki).

Diese Subroutinen hatte ich beim Anpassen übersehen.

Bedeutet dies, dass es constant Namen auch nur einmal geben darf und ich die constant Namen auch noch alle ändern muss?
z.B. von SDUINO_VERSION in SDUINOA_VERSION

Gruß Ralf