Signalduino vs. Signalduino

[carlos]

Wenn es tatsächlich nicht möglich ist beides zusammen zu nehmen, würde ich das auch unterstützen.
Gruß

Hubert

[KölnSolar]

Auch ich bin für eine strikte Trennung durch eindeutige Benennung der Module.
Macht vieles klarer. Auch nach Jahren...
Grüße Markus

[Beta-User]

Prinzipiell macht mir der support-Aufwand für eine eventuelle Umstellung echt Sorge! Im Moment bin ich eher nicht überzeugt, dass sich eine "Doppler-Aktion" wirklich lohnt und fürchte sehr viele verärgerte User!

Andererseits muss man sich (nach meinem eventuell falschen Verständnis) heute (pro FHEM-Instanz) entscheiden, welche Fassung man denn gerne hätte. Je nach Umfeld kann das auch ein Problem sein...

Tendenziell wäre es super, wenn wir wieder auf einen einheitlichen Weg kämen mit "best of both worlds"! (Ist mir klar, dass das für beide maintainer der größere Aufwand wäre, aber m.E. wäre das besser, als in der Übergangsphase die User komplett zu verwirren....)

[Ralf9]

Prinzipiell macht mir der support-Aufwand für eine eventuelle Umstellung echt Sorge! Im Moment bin ich eher nicht überzeugt, dass sich eine "Doppler-Aktion" wirklich lohnt und fürchte sehr viele verärgerte User!

Ja, das denke ich auch, auch wenn ich dann Hinweise und Warnungen dazuschreibe, werden dann einige auf das neue umbenannte Modul updaten, ohne die Hinweise zu beachten, und dann hier schreiben, daß der sduino nicht mehr funktioniert.

Es wird dann auch kein einfacher wechsel zwischen den 00_SIGNALduino Modulen möglich sein.

Bei slowrf (ASK/OOK) sollte eigentlich kein Parallelbetrieb beider Versionen notwendig sein.
Mit meinem 00_SIGNALduino Modul können auch sduinos mit der firmware von sidey verwendet werden.
Wenn sidey beim 00_SIGNALduino Modul bei den parse Routinen die regex entschärfen würde, könnten auch sduinos mit meiner firmware verwendet werden.

Bei FSK ist ein parallelbetrieb nur mit recht großem Aufwand machbar.
Eine Umbenennung von meinem 14_SD_WS Modul ist nicht praktikabel, es müssten dann alle SD_WS devices gelöscht und wieder neu eingerichtet werden.
Bei Bedarf könnte ich mein 14_SD_WS Modul so anpassen und ergänzen, daß es auch bei FSK mit dem 00_SIGNALduino Modul von sidey verwendet werden kann.

[rudolfkoenig]

Wenn eine komplette Zusammenführung nur mit unvertretbaren Aufwand verbunden ist, dann bin ich auch fuer eine Umbenennung.
Was Vergleichbares gibt es auch mit CUL vs. CUL_TS.

[Steigerbalett]

Prinzipiell macht mir der support-Aufwand für eine eventuelle Umstellung echt Sorge! Im Moment bin ich eher nicht überzeugt, dass sich eine "Doppler-Aktion" wirklich lohnt und fürchte sehr viele verärgerte User!

Was spricht dagegen SIGNALduinoADV ein neues Github Repositry zu spendieren und damit die Supportproblematik verägerter User zu umgehen?
Dann muss man aktiv die Updatequelle umstellen und sollte daher dann auch wissen, dass man seine Devices einmal neu anlernen muss.

Tendenziell wäre es super, wenn wir wieder auf einen einheitlichen Weg kämen mit "best of both worlds"!

Ja, aber das sieht für mich nach noch deutlich mehr Aufwand für die Maintainer aus als die Supportproblematik.

[ph1959de]

Wäre es nicht möglich, das Modul zu einer Art Stub zu machen, der dann "das richtige" Modul (oder entsprechende Routinen innerhalb des Moduls) aufruft? Wäre es damit möglich, anhand des bestehenden Devices / der "angebundenen" Firmware die "richtigen Entscheidungen" zu treffen? Mit der Problematik, dass ein eigentlich "RalfDuino" Device mit dem "SideyDuino" Modul (und umgekehrt) angesprochen wird, müssten die beiden Module doch bereits umgehen können?

In meiner (zu naiven?) Vorstellung müsste sich doch damit der Umstieg für die Benutzer transparent gestalten lassen, es müssen keine Devices migriert werden und ein Parallelbetrieb der beiden Typen sollte mögliche sein?

[Ralf9]

Bei einer Umbenennung in 00_SIGNALduinoADV.pm müssen dann als ersten Schritt erst mal einige Client Module angepasst werden.
Auf die schnelle habe ich die folgenden Module gefunden:

10_IT.pm

Code Auswählen Erweitern

if ($io->{TYPE} ne "SIGNALduino") {
in
if ($io->{TYPE} ne "SIGNALduino" && $io->{TYPE} ne "SIGNALduinoADV") {
10_SOMFY.pm

Code Auswählen Erweitern

if ($ioType eq "SIGNALduino") {
in
if ($ioType eq "SIGNALduino" || $ioType eq "SIGNALduinoADV") {

if ($ioType ne "SIGNALduino") {
in
if ($ioType ne "SIGNALduino" && $ioType ne "SIGNALduinoADV") {
14_CUL_TCM97001.pm

Code Auswählen Erweitern

if (($readedModel eq "Eurochron" || (hex($a[6]) == 0xF && $readedModel eq "Unknown" && $hash->{TYPE} ne "SIGNALduino") && $syncBit[1] < 5000)) {
in
if (($readedModel eq "Eurochron" || (hex($a[6]) == 0xF && $readedModel eq "Unknown" && $hash->{TYPE} ne "SIGNALduino" && $hash->{TYPE} ne "SIGNALduinoADV") && $syncBit[1] < 5000)) {

Was spricht dagegen SIGNALduinoADV ein neues Github Repositry zu spendieren und damit die Supportproblematik verägerter User zu umgehen?

Ja das wäre wahrscheinlich am praktikabelsten
Dann wäre es in github kein fork mehr.
Ich müsste dann in das neue Github Repositry SIGNALduinoADV z.B. eine Version von 2018 commiten und dann die commits per cherry pick rüber holen.

Wäre es nicht möglich, das Modul zu einer Art Stub zu machen,

das sagt mir nichts

[rudolfkoenig]

Code Auswählen Erweitern

Wäre es nicht möglich, das Modul zu einer Art Stub zu machen,Das ist im Prinzip moeglich (analog zu Interface oder abstrakte Klasse), allerdings bleibt das Problem des Supports: man uebersieht leicht, welche Implementierung gerade verwendet wird.
Auch die "statische" Dokumentation wird dadurch umstaendlich.

[ph1959de]

Code Auswählen Erweitern

Wäre es nicht möglich, das Modul zu einer Art Stub zu machen,Das ist im Prinzip moeglich (analog zu Interface oder abstrakte Klasse), allerdings bleibt das Problem des Supports: man uebersieht leicht, welche Implementierung gerade verwendet wird.
Auch die "statische" Dokumentation wird dadurch umstaendlich.

Schwieriger als es jetzt gerade ist, kann es aber fast nicht mehr werden 

[Ralf9]

Wenn nichts dagegen spricht habe ich folgendes vor:
- neues repository SIGNALduinoADV
- importieren des repository 14_SD_WS, damit das 14_SD_WS und das 00_SIGNALduinoADV im selben repository sind
- eine Version von 2018 des 00_SIGNALduino commiten und dann die commits per cherry pick rüber holen.
  beim cherry pick werde ich wahrscheinlich Hilfe benötigen
- das 14_SD_WS Modul so ändern damit es auch bei FSK mit dem 00_SIGNALduino Modul von Sidey funktioniert

[Ralf9]

Ich habe inzwischen ein neues Repro angelegt
https://github.com/Ralf9/SIGNALduinoADV_FHEM
und das bisherige repro importiert und dann per merge rebase das dev nach main gebracht.

Nun möchte ich die 23 commits
https://github.com/Ralf9/14_SD_WS/commits/main
rüber holen.

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

[Sidey]

Also meine 5ct zum Thema:

Man kann prinzipiell alles wieder in ein Projekt zusammenführen und die Lizenzverstöße beenden.

Das ist aber ziemlich viel Aufwand, da die Veränderungen einzeln überführt werden müssten.
Welche und wie viele das sind weiss ja nur Ralf9.

[Sidey]

Ich möchte das Thema auch mal aufgreifen.
Mittlerweile kann man ja eigentlich von zwei parallellaufenden Projekten sprechen. Beide sind weit verbreitet und haben jeweils ihre "Anhängerschaft". Eine gleichzeitige Nutzung ist aktuell nicht möglich. Ich habe auf der Suche nach einem funktionierenden Decoder für ein Signal diverse Versuche unternommen und dabei auch immer mal wieder von der Version von Sidey zur Version von Ralf9 gewechselt.

Da Du ja beide intensiv getestet hast.
Hast Du mal ein Beispiel, was die Ursprungsversion nicht empfängt? Mir ist da nichts bekannt, was die Ursprungsfirmware nicht empfangen kann. Das einzige, was ich mir vorstellen könnte, ist dass es Protokolldefinition gibt, die nicht für beide Varianten existieren.
Die sind aber beim Ursprungsprojekt schon seit langem vom Modul entkoppelt und unabhängig vom IO Modul.

Grüße Sidey

[Steigerbalett]

Hallo Sidey,
ich bin damals z.B. wegen der besseren Somfy-Unterstützung zur Version von Ralf gewechselt... Auch gefallen mir die Einstellungsmöglichkeiten bei seiner Version besser.