Readings, values und Units

[Dr. Boris Neubert]

Hallo Martin,

- gescheitert (oder political correct: bis auf weiteres verschoben)

wie kommst Du denn darauf?

Wir sind doch schon unglaublich weit gekommen. Und mir scheint, daß diejenigen, die zuletzt noch mitdiskutiert haben, doch schon auf einem Konsens sind, wie es gemacht werden soll (Details noch zu bestimmen).

Mir fehlt derzeit aber noch die breitere Basis an Entwicklern, die dem Vorschlag auch zustimmen sollte. Möglicherweise haben viele zwischendurch den Faden verloren. Hallo, ist da draußen jemand?

Ich denke, daß wir den Lösungskandidaten dokumentieren sollten (bin für eine Seite im Wiki, an der wir gemeinsam herumschrauben) und dann mit einem neuen Thread in die zweite Runde gehen. Die Dokumentation hilft nämlich dem gemeinsamen Verständnis (ich weiß, was ich verstanden habe und will, aber ich weiß nicht, ob Ihr das gleiche verstanden habt und wollt). Sie zeigt zudem, daß die Diskussion nicht tot ist und daß wir weitergekommen sind und was wir von den anderen Entwicklern erwarten.

Viele Grüße
Boris

P.S.: Ich war wieder die ganze Woche im Ausland und bin daher sehr froh, daß ich mich jetzt nicht durch hunderte Beiträge zu diesem Thema wühlen muß.

[martinp876]

Hallo Boris,
nun, ich sehe, dass keiner weiter macht, und es sehr wenige interessiert, zumindest arbeitet keiner weiter - egal in welche Richtung.
Unklar ist mir, wer der owner des Readings-Objekts sein wird. Dieser könnte einen Versuch starten. Das Konzept wäre klar, die Realisierung läge bei ihm. Die Parameter sind für das Konzept zweitrangig - das konzept müsste eh hergeben, dass es erweitert werden kann. Wichtig wären die Zugriffsmethode. Die "interne Architektur" geht ist prinzipiell  design Angelegenheit.
Wie du selbst korrekt bemerkst: keine Beteiligung. Das sehe ich als klares votum: kein Interesse. Auch eine Art Abstimmung.
Gruss Martin

[oliv06]

I am interested in this subject but google translation is not clever enough to let me understand clearly the options 

[Markus Bloch]

Ich versteh gerade dein Problem nicht so ganz, Martin.

Wir haben hier in den vergangenen Posts versucht uns klar zu machen, das was geändert werden muss. Das denke ich haben wir auch geschafft.

Es wurde auch klar dargelegt, das man nicht nur fluchs einen Wert {UNIT} im Reading unterbringen sollte, sondern dass das ganze genereller angegangen werden muss (Stichwort: Typendefinitionen).

Dazu wurden noch weitere Sachen genannt wie z.B. Umrechungsformeln (für Frontends).

Desweiteren sind wir übereingekommen, dass solche Typendefinitionen in FHEM separat bereitstehen sollten (z.B als %types) und die Module alle numerischen Readings diesen Typen zuordnen. Daraus folgt für mich, die numerischen Werte bleiben so wie sie sind, ohne Einheit hinten drann und man kann mit ReadingsVal diese Werte für Berechnungen nehmen, was ja auch eine deiner Kernforderungen war (korrigier mich, wenn ich falsch liege).

Das ist allerdings nun nur eine Lösung die innerhalb von einer Hand voll Leuten diskutiert wurde. Alle anderen Entwickler und auch Rudi haben sich dabei noch garnicht eingebracht. Aufgrund dieser elementaren Änderungen muss das aber auf jedenfall geschehen. (Wie es Boris beschrieben hat).

Wo ich dir zustimme ist momentan die Frage nach dem Verantwortlichen für dieses Thema. Da sehe ich momentan auch noch eher Nebel. Ich denke, das sollte man noch durchaus klären.

Aber ich kann dir keinesfalls zustimmen, dass diese Diskussion versandet ist, oder zu keinem Ergebnis gekommen ist.

[betateilchen]

Ich versteh gerade dein Problem nicht so ganz, Martin.

Dann sind wir mindestens schon zwei, die das nicht verstehen.

[justme1968]

drei... 

genau so wie du es zusammengefast hast hatte ich es auch verstanden.

[papa]

vier ....

Ich habe mich nur zurück gehalten, weil ich nicht sehr FHEM-Entwicklungsprozess-erfahren bin und mir nicht klar ist, wie hier solche grundlegenden Änderungen angegangen werden. Meine Perl-Kenntnisse halten sich auch eher in Grenzen. Da kann ich weniger konkrete Vorschläge machen. Aber für Architektur-Fragen und sowas gebe ich gern meine Erfahrungen weiter.

BTW: Sollte man sich vielleicht auch gleich mal über eine Testsuite Gedanken machen, welche die Modulentwickler nutzen könnten, um Ihre Implementierungen gegen die API testen zu können ?

[betateilchen]

dazu muss man erstmal wissen, wie die API aussieht 

[hexenmeister]

Fünf
Ich verfolge die Diskussion mit Interesse und finde, sie geht durchaus in die richtige Richtung.
Ich bin selbst noch nicht so tief in der Materie drin, daher nehme erstmal eine passive Rolle ein. Vorläufig

[martinp876]

nun, melden sich doch welche. Schon ein Erfolg...

Wo sind aber die Antworten
- wer wird den Implementierung des Objekts realisieren?

dazu muss man erstmal wissen, wie die API aussieht

- wo sind die Vorschläge?

Wenn es kein passendes API gibt funktioniert es nicht - egal wie die Semantik der Objekte sein könnte.

Aktuell sehe ich nur eine einzige Idee, dass es quasi ein Objekt wird. Noch kein Beschluss.  Alles andere sind mehr  neblige Ideen, welche Attribute das Objekt haben könnte. Das API ist noch viel weiter im Nebel.

Interessiert scheinen einige zu sein - schön. Das habe ich auch. Muss man unbedingt haben, an solche einer Zentralen Stelle.  Aber es wird ein Macher gebraucht. So lange dieser nicht benannt ist und  agiert steht das hier. Auch nach den letzten Wortmeldungen sehe ich nur Stillstand.

Gruss
Martin

[betateilchen]

mit deiner Drängelei wirst Du auch keine schnelle Lösung erzwingen, ganz im Gegenteil...

[Dr. Boris Neubert]

Hallo Martin,

ich empfinde das auch als Drängelei.

Du suchst jemanden, der das in die Hand nimmt. Das kann ich tun. Das bedeutet, daß ich recht viel Arbeit in diese Sache investieren werde, die ich nur über einen längeren Zeitraum (Monate) verteilt erübrigen kann. Ich halte es aber heute wie 2010 für wichtig für FHEM, und deswegen setze ich mich dafür ein.

Ich lehne es ab, irgendwelche Module hier zu posten. Es wird einen Development-Branch im SVN geben. Darum kümmere ich mich als erstes. Der Stable-Branch würde regelmäßig in den Development-Branch gemergt werden.

Dann werde ich einen Minimalentwurf als Proof-of-Concept zum Review einchecken. Dazu werde ich ein Typen-Modul mit Convenience-Methoden bauen, ein Gerätemodul für eine Geräteklasse, die ich nutze, anpassen, und in FHEMWEB entsprechende Anpassungen machen. Ich gehe mal davon aus, daß im Development-Branch die Regel, daß jeder nur seine Module anfaßt, nicht greift.

Viele Grüße
Boris

[martinp876]

Hallo Boris,

ich empfinde das auch als Drängelei.

vielleicht. Das Klären der Zuständigkeiten oder zumindest das Benennen eines chair hat aber nichts mit Drängeln zu tun, es legt ja keinen Zeitplan fest. Das ist nur ein Minimum an Logistik und strukturiertem Arbeiten.

Du suchst jemanden, der das in die Hand nimmt.

ich suche? nun ja, kann man so sehen. Wie läuft das sonst hier? Ich kenne Zuständigkeiten für Module. Dies ist aber eine Zentralfunktion - wird evtl auch ein Modul... . Ich hätte erwartet, dass sich einer der "Herren-des-Kernal" hier einbringen wird und dies deutlich macht. Das hast du jetzt übernommen, gut.

Ich halte es aber heute wie 2010 für wichtig für FHEM

volle Zustimmung. Daher ist der strukturierten Ablauf um so wichtiger.

Dazu werde ich ein Typen-Modul mit Convenience-Methoden bauen, ein Gerätemodul für eine Geräteklasse, die ich nutze, anpassen, und in FHEMWEB entsprechende Anpassungen machen.

nun, ich erwarte eins nach dem Anderen. FHEMWEB ist sicher der letzte Schritt. Wir reden hier doch von Entwicklern??? Die sollten sich einen Eindruck auch ohne das Frontend verschaffen können. Mir würde eins nach dem Anderen reichen. Wichtiger wäre eine gute Doku mit den geplanten APIs.

Ich gehe mal davon aus, daß im Development-Branch die Regel, daß jeder nur seine Module anfaßt, nicht greift.

ui, ist das so? Warum? Wie sind hier die Regeln?

Gruss Martin

[betateilchen]

die ich nutze, anpassen, und in FHEMWEB entsprechende Anpassungen machen.

Hallo Boris,

beachte dabei bitte, dass Rudi gerade ein paar grundlegende Änderungen von FHEMWEB in der Planung hat. Nicht dass Du Dir Arbeit mit der "alten" FHEMWEB machst und danach alles nochmal machen musst.

Ich denke auch dass die Darstellung in FHEMWEB der allerletzte Schritt sein wird. Ein stabiles Backend ist bei dieser Sache m.E. erstmal sehr viel wichtiger.

Viele Grüße
Udo

[Dr. Boris Neubert]

Hallo,

zum Frontend: man kann sich ja viel fürs Backend ausdenken. Aber das richtige Gespür dafür, ob das Design auch wirklich was taugt, bekomme ich erst, wenn ich es einsetze und sehe, wie es sich für den Verwender anfühlt. Daher die Idee für einen Durchstich, ein Proof-of-Concept eben.

zum Development-Branch: da es so etwas bisher nicht (offziell) gibt, gibt es auch keine Regeln dafür. Aber wie kann ich ein Gefühl dafür entwickeln, wie das Frontend mit den Typen im Backend umgeht, wenn ich es nicht selbst programmiere. Das kann man immer noch wegwerfen oder später vom Maintainer aus dem Development-Branch in den Stable-Branch mergen lassen.

Ich hoffe, daß meine Ideen deutlicher geworden sind.

Viele Grüße
Boris