Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ToDos übernahme von Signalduino Modulen ins SVN #163

Closed
34 of 45 tasks
Ralf9 opened this issue Jun 20, 2017 · 26 comments
Closed
34 of 45 tasks

ToDos übernahme von Signalduino Modulen ins SVN #163

Ralf9 opened this issue Jun 20, 2017 · 26 comments

Comments

@Ralf9
Copy link
Contributor

Ralf9 commented Jun 20, 2017 •
edited by sidey79

In SVN wurden am 18.11.17 folgende von Master übernommen:

  • 00_SIGNALduino.pm (SVN=master)
  • 14_Hideki.pm (SVN=master)
  • 14_SD_RSL.pm
  • 14_SD_WS.pm (SVN=master)
  • 14_SD_WS07.pm (SVN=master)
  • 14_SD_WS09.pm (SVN=master)

Folgende Module wurden nicht übernommen:

  • 14_SD_AS.pm
  • 14_SD_UT.pm -> item summary und englische Device specific help fehlt (kommt erst mal nicht ins SVN, da auch de Maintainer Frage unklar ist)
  • 10_FS10.pm (Maintainer und Supportforum unklar)
  • 14_FLAMINGO.pm (maintainer Frage unklar)
  • 14_BresserTemeo.pm (maintainer Frage unklar)

Folgende Module sind unverändert im SVN:

  • 14_SD_WS_Maverick.pm (bereits aktuell)
  • 41_OREGON.pm (bereits aktuell)
  • 90_SIGNALduino_un.pm (bereits aktuell)
  • 98_Dooya.pm (bereits aktuell

Englische Commandref

  • 00_SIGNALduino.pm
  • 10_FS10.pm
  • 14_FLAMINGO.pm
  • 14_Hideki.pm
  • 14_SD_AS.pm
  • 14_SD_RSL.pm
  • 14_SD_UT.pm
  • 14_SD_WS.pm
  • 14_SD_WS07.pm
  • 14_SD_WS09.pm
  • 14_SD_WS_Maverick.pm (SVN = dev-r33)
  • 41_OREGON.pm (SVN = dev-r33)
  • 90_SIGNALduino_un.pm (SVN = dev-r33)
  • 98_Dooya.pm (SVN = dev-r33)
  • 14_BresserTemeo.pm (itemsummary fehlt)

Deutsche Commandref

  • 00_SIGNALduino.pm
  • 10_FS10.pm
  • 14_FLAMINGO.pm
  • 14_Hideki.pm
  • 14_SD_AS.pm
  • 14_SD_RSL.pm
  • 14_SD_UT.pm
  • 14_SD_WS.pm
  • 14_SD_WS07.pm
  • 14_SD_WS09.pm
  • 14_SD_WS_Maverick.pm (SVN = dev-r33)
  • 41_OREGON.pm (SVN = dev-r33)
  • 90_SIGNALduino_un.pm (SVN = dev-r33)
  • 98_Dooya.pm (SVN = dev-r33)
  • 14_BresserTemeo.pm (itemsummary fehlt)
@andreasloe
Copy link

Kann man das Brennenstuhl-Problem evtl lösen: https://forum.fhem.de/index.php?topic=73410.msg650626#msg650626

sidey79 pushed a commit that referenced this issue Jun 25, 2017
@Kolbi @sidey79
Update 14_FLAMINGO.pm (#164)
e411685 
Item Summary 14_Flamingo added #163

@Ralf9: Solange der Perl Prozess im richtigen VZ aufgerufen wird, klappt das auch ohne ./
Nur interessant ist, wieso das fehlt.
@sidey79
Copy link
Contributor

sidey79 commented Aug 30, 2017

@Ralf9

ich würde das Thema langsam mal gerne abschließen.

Fehlermeldungen durch das Modul habe ich schon gesucht und auch versucht zu beheben.

Ein bisschen unklar ist das mit der Firmware aktuell noch.
so wie ich das sehe, gibt es im aktuellen Master das Problem mit dem invertieren nicht. Das Modul würde mit der alten und der neuen Firmware dann ohne invertieren der MC Nachricht am besten laufen.
Nur die Development Zwischen ersinnen hätten ein Problem.

@Ralf9
Copy link
Contributor Author

Ralf9 commented Aug 30, 2017

Ich habe mir nochmals Gedanken über meine Idee mit den Development Ids gemacht.
Ich würde es gut finden, wenn bei der 00_SIGNALduino.pm beim normalen fhem update die gleiche Version verwendet würde wie die dev Version im github.
Dann würden die Probleme wegfallen, wenn jemand ein fhem update macht und vergisst hinterher ein github update zu machen.
Ich würde dazu ein neues Attribut (z.B. "devVersion") einführen.
Wenn das Attribut devVersion = 1 ist, dann ist die 00_SIGNALduino.pm eine dev Version und die Development Ids werden verwendet.

Bei den aktuellen Master und dev Firmware hex Files werden die MC Nachrichten invertiert.
Das Problem mit dem invertieren/nicht invertieren kommt erst durch die dev-r33_fixmc.

Solange Du nicht rausgefunden hast warum bei der dev-r33_fixmc es Probleme mit dem erkennen des Anfangs gibt, würde ich damit keine Firmware hex Files bauen.

@sidey79
Copy link
Contributor

sidey79 commented Aug 30, 2017

Also die dev Version hat im SVN nichts zu tun.

Das Problem was wir aktuell haben ist, dass wir immer an 10 Stellen gleichzeitig etwas machen.
Wenn wir die Protokolldefinitionen von dem restlichen Code trennen könnten, dann wäre das schon ein riesen Fortschritt, denn das mit dem development ids klappt gut für Protokollerweiterungen.
Für grundlegende Änderungen im Modul nutzt uns das wenig.

Und ganz wichtig, wir müssen das öfters updaten, sonst verzetteln wir uns.

Was die Firmware angeht, ich habe bisher keine Daten, was da passiert. Daher würde ich die FW im dev Branch einstellen, damit diese von mehr Anwender getestet wird.

@Ralf9
Copy link
Contributor Author

Ralf9 commented Aug 30, 2017

Wenn bei der aktuellen dev Version der 00_SIGNALduino.pm die development id nicht verwendet werden, was passt dann nicht fürs SVN?

@sidey79
Copy link
Contributor

sidey79 commented Aug 30, 2017

Genau jetzt aktuell würde es vermutlich passen, aber wenn wir etwas funktional ändern, dann kann man das nicht direkt ins fhem update einbauen, da die development id keine relevanz hat.

Man könnte natürlich den Code mittels "development release" Bedingungen verändern, dann würde es gehen und der Anwender kann zwischen stable / dev umschalten. Das kann aber komplex werden, wenn z.B. Parameter für Funktionen geändert werden.

@Ralf9
Copy link
Contributor Author

Ralf9 commented Aug 30, 2017

Ist ja nur ein Vorschlag, Du kannst es gerne so machen wie Du es Dir vorstellst.

@Ralf9
Copy link
Contributor Author

Ralf9 commented Aug 31, 2017

Bis auf das 14_SD_UT Modul müssten alle Module soweit passen, daß Du sie ins SVN übernehmen kannst

@sidey79
Copy link
Contributor

sidey79 commented Nov 14, 2017

@Ralf9

Was meinst Du, passt das mittlerweile alles?

@Ralf9
Copy link
Contributor Author

Ralf9 commented Nov 14, 2017

Ja, bis auf eine fehlende enlische Übersrtzung müsste es soweit passen.

@sidey79
Copy link
Contributor

sidey79 commented Nov 15, 2017

Okay, schau ich mir heute noch an. Ich habe es bei mir jetzt Mal mit der alten 3.2 FW am laufen. Die würde ich erst mal beibehalten und nur die Module in das SVN übernehmen

@sidey79
Copy link
Contributor

sidey79 commented Nov 15, 2017

Sieht eigentlich ganz gut aus.... Wie ist das mit den restlichen Modulen? Die müsste man ja am besten gleich mit ins SVN übernehmen

@sidey79
Copy link
Contributor

sidey79 commented Nov 15, 2017

@Ralf9

Eigntlich sieht es ganz gut aus oder?
Bei einigen fehlt ne englische commandref, naja finde ich jetzt nicht sonderlich tragisch eher unschön.

@Ralf9
Copy link
Contributor Author

Ralf9 commented Nov 15, 2017

Außer beim 14_SD_UT.pm müsste es eigentlich bei allen Modulen passen.
Bei welchen Modulen fehlt die englische commandref?

@sidey79
Copy link
Contributor

sidey79 commented Nov 15, 2017

@Ralf9
SD_UD und SD_AS würde ich nicht ins SVN übernehmen.

@Ralf9
Copy link
Contributor Author

Ralf9 commented Nov 15, 2017

Dann müsste beim SD_AS noch folgendes in die Protokolldefinition:

name	=> 'AS, Self build arduino sensor'
comment         => 'developModule. SD_AS module is only in github available',
developId => 'm',

@sidey79
Copy link
Contributor

sidey79 commented Nov 15, 2017

@Ralf9
Ich hab mal nach der commandref geschaut und deinen 1. Beitrag etwas angepasst / erweitert.

@sidey79
Copy link
Contributor

sidey79 commented Nov 15, 2017

#130

@sidey79
Copy link
Contributor

sidey79 commented Nov 15, 2017

@Ralf9
okay SD_AS Protokoll ist angepasst

@sidey79
Copy link
Contributor

sidey79 commented Nov 17, 2017 •
edited

@Ralf9

Da unklar ist, was mit
10_FS10.pm (wer macht da den maintainer?)

passiert, würde ich das erst mal zurückstellen und den Rest halt ins SVN bringen oder fehlt uns noch etwas? Mal sehen, was ich in das Changelog schreibe... das kriege ich ja bestimmt nicht mehr zusammen, was da alles geändert wurde

  • Blacklist Support
  • Serval new Protocols
  • Stability improvements
  • Flash firmware from http source
  • Sendqueue
  • many more fixes
  • cc1101 support

@Ralf9
Copy link
Contributor Author

Ralf9 commented Nov 17, 2017

Du hast was nicht ganz unwichtiges vergessen, den cc1101 support

@sidey79
Copy link
Contributor

sidey79 commented Nov 17, 2017

@Ralf9
okay.

@sidey79
Copy link
Contributor

sidey79 commented Nov 18, 2017

@Ralf9

So, den Masterbranch habe ich angepasst.

@sidey79
Copy link
Contributor

sidey79 commented Nov 18, 2017 •
edited

So ich habe nun einen Teil der Module aktualisiert:
https://svn.fhem.de/trac/changeset/15450/trunk/fhem
und
https://svn.fhem.de/trac/changeset/15451/trunk/fhem

@sidey79
Copy link
Contributor

sidey79 commented Nov 18, 2017

@Ralf9

  1. Post aktualisiert, da ein paar Module im SVN aktualisiert wurden

@sidey79 sidey79 closed this as completed Mar 29, 2018
@HomeAutoUser
Copy link
Contributor

HomeAutoUser commented Oct 10, 2018 •
edited

@sidey79 & @Ralf9
da wir auf der ToDo Liste oeben stehen haben

14_FLAMINGO.pm (maintainer Frage unklar)

gehe ich davon aus, dies stammt von uns? Liege ich da richtig?
Ich frage, da ich ein Model ergänzen würde und ggf in dem Modul den Code anpssen würde.

LG

EDIT: Ich passe das Modul bestmöglich "an" und werde einen PR erstellen. Beim Umschreiben habe ich mitbekommen das das Modul einen "angefangen" Zustand macht und manches nicht funktioniert bzw. funktionieren kann.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@sidey79 @andreasloe @Ralf9 @HomeAutoUser