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.