eBus Schaltung in Betrieb nehmen

[john30]

In der Zwischenzeit bin auch auf ein anderes Problem gestoßen:
Vorlaufzeit interne Heizkreispumpe - ebusctl r -f -c ehp#install  AWHc1PumpPrerunTime
Bekomm ich immer Element not found. Das selbe mit HwcHwcHc1PumpPrerunTime

Mit vrDialog kann ich diesen Wert normal lesen.

Wie kann ich den HeatPumpType sowie SW-Version auslesen, damit ich das kontrollieren kann?

Die SW Version steht z.B. im "info" Ergebnis und den HeatPumpType kannst Du einfach auslesen, der sollte bei Dir airtobrinetowater sein, wenn mich nicht alles täuscht.

[john30]

Bezgl. den OMU Timern, bekomm ich immer UNKNOWN Commands in der ebusd.log
John, reicht dir das aus, oder soll ich noch etwas machen?
Auf Höhe NoiseReductionFactor habe ich dann auch am Fenstertyp (Mo-Fr, Mo-So...) gedreht:

Das ist ein bisschen viel. Du müsstest mir schon sagen, wann genau Du den Timer geändert hast, damit ich die zugehörige unknown message finde. Am besten Du stellst ein paar markante Werte der Reihe nach ein, und gibst mir dann jeweils die unknown message dazu, also bspw.:
- Mo-So 00:00-12:00
- Mo 00:00-22:00
- Di 06:00-23:00
- Mo-Fr 08:00-13:00
- Sa-So 09:00-18:00

sowas in der Art

[john30]

PS: gibt es eigentlich noch Funktionswünsche für 98_GAEBUS?

Ich versuche gerade, Dein Modul in Betrieb zu nehmen.
Wie bekomme ich denn jetzt readings in FHEM? Irgendwie verstehe ich die Funktionsweise noch nicht richtig.
Also habe mal find ausgeführt und nun sind die Nachrichten alle da, das passt.
Jetzt hätte ich erwartet, dass ein get einer Nachricht auch ein entsprechendes Reading erzeugt, was aber nicht der Fall ist. Wie bkommt man das hin?

[jamesgo]

Hallo John,

mit get kannst du die Werte erst mal nur interaktiv abfragen.
Wenn du ein Reading willst, musst du einen set ausführen, das erzeugt dir ein Attribut ohne Wert.
Den Wert des Attributes setzt du auf den Wunschnamen für das Reading.
Danach gibt es "get reading ..." (evil noch ein refresh im Browser)

Grüße
Andy

[john30]

Vorlaufzeit interne Heizkreispumpe - ebusctl r -f -c ehp#install  AWHc1PumpPrerunTime
Bekomm ich immer Element not found. Das selbe mit HwcHwcHc1PumpPrerunTime

Noch was dazu:
Es waren leider zwei Bugs im ebusd beim Parsen der Conditions. Deshalb waren seit April Messages ala [SW=xx] oder [SW=304-305] generell nicht verfügbar
Da wird es wohl demnächst ein neues Release geben müssen
Die Probleme sind mit commit https://github.com/john30/ebusd/commit/6311149 gefixt.

[john30]

mit get kannst du die Werte erst mal nur interaktiv abfragen.
Wenn du ein Reading willst, musst du einen set ausführen, das erzeugt dir ein Attribut ohne Wert.
Den Wert des Attributes setzt du auf den Wunschnamen für das Reading.
Danach gibt es "get reading ..." (evil noch ein refresh im Browser)

okay, da wär ich jetzt niemals drauf gekommen nach Lesen der Device doku. Schätze das müsste man noch etwas verfeinern
Wäre vielleicht ein schönes Feature, hier per default den Namen der Message (circuit+Name) zu übernehmen. Denn ohne dafür ein Reading haben zu wollen, würde ich ja nicht den set aufrufen, oder?
Pollt gaebus dann die Readings?

[jamesgo]

ja, die Readings werden gepollt. Durch Anhängen von z.B. ":5" wird die Abfrage nur jedes 5-te mal gemacht. (Polls modulo 5 seit start von fhem)
Du kannst mehrere Readings angeben - falls mehr als ein Wert zurückgegeben wird "z.B. dummy;temp".
Und es gibt noch das Attribut "valueFormat" mit dem jedes Reading noch formatiert werden kann.

[john30]

ja, die Readings werden gepollt. Durch Anhängen von z.B. ":5" wird die Abfrage nur jedes 5-te mal gemacht. (Polls modulo 5 seit start von fhem)
Du kannst mehrere Readings angeben - falls mehr als ein Wert zurückgegeben wird "z.B. dummy;temp".
Und es gibt noch das Attribut "valueFormat" mit dem jedes Reading noch formatiert werden kann.

Was in der Doku noch fehlt: Beschreibung von "h" (statt "r").

[jamesgo]

Du meinst "read -h" (also hex)? Das fehlt nicht in der Beschreibung, sondern in der Implementierung.
Aber es wäre ein nettes feature ... mal schaun.

[Marie01]

Noch was dazu:
Es waren leider zwei Bugs im ebusd beim Parsen der Conditions. Deshalb waren seit April Messages ala [SW=xx] oder [SW=304-305] generell nicht verfügbar
Da wird es wohl demnächst ein neues Release geben müssen
Die Probleme sind mit commit https://github.com/john30/ebusd/commit/6311149 gefixt.

Servus John!

Danke für die Info.
Kann ich das jetzt selber schon irgendwie fixen oder muss ich auf dein Relese warten?

[Marie01]

Das ist ein bisschen viel. Du müsstest mir schon sagen, wann genau Du den Timer geändert hast, damit ich die zugehörige unknown message finde. Am besten Du stellst ein paar markante Werte der Reihe nach ein, und gibst mir dann jeweils die unknown message dazu, also bspw.:
- Mo-So 00:00-12:00
- Mo 00:00-22:00
- Di 06:00-23:00
- Mo-Fr 08:00-13:00
- Sa-So 09:00-18:00

sowas in der Art

Mach ich im Laufe dieser Woche! Danke für deine Hilfe!

[john30]

Du meinst "read -h" (also hex)? Das fehlt nicht in der Beschreibung, sondern in der Implementierung.
Aber es wäre ein nettes feature ... mal schaun.

Nö, meinte eigentlich das, was in der Beschreibung erwähnt aber nicht erklärt ist: r|h

[john30]

Danke für die Info.
Kann ich das jetzt selber schon irgendwie fixen oder muss ich auf dein Relese warten?

Klar, einfach den aktuellen git source nehmen.

[jamesgo]

Nö, meinte eigentlich das, was in der Beschreibung erwähnt aber nicht erklärt ist: r|h

Hallo John30,

da muss ich jetzt passen. Im Code finde ich, dass "h" wie "r" behandelt wird. In meinen Definitionen für Vaillant gibt es aber keine Einträge mit "h".

Kannst du mir zwei Zeilen posten was du im commandref gerne hättest?

Danke
Andy

[john30]

da muss ich jetzt passen. Im Code finde ich, dass "h" wie "r" behandelt wird. In meinen Definitionen für Vaillant gibt es aber keine Einträge mit "h".

Kannst du mir zwei Zeilen posten was du im commandref gerne hättest?

ich meinte folgendes: in der Doku vom Modul GAEBUS steht "Attributes of the format [r|h]..." aber es ist nirgends erklärt was das "h" anstelle eines "r" tut.