Plugin Pelletkessel

[callidomus]

Hallo,

So geht soweit. Prima.

klasse, freu mich auf das neue Plugin!

Bis bald

Marcus

[greentux]

So geht soweit. Prima.
Ich kann jetzt Items anlegen ala:

[etatest]
    [[testuri1]]
       eta_pu_uri = 112/10021/0/0/12000
       type = str
       [[[strValue]]]
           eta_pu_type = strValue
           type = str
       [[[unit]]]
           eta_pu_type = unit
           type = str
    [[testuri2]]
       eta_pu_uri = 112/10021/0/0/12162
       type = str
       [[[strValue]]]
           eta_pu_type = strValue
           type = str
       [[[unit]]]
           eta_pu_type = unit
           type = str

Und es gibt die Werte zurück.
Das muss ich jetzt noch ein wenig aufhübschen, Kommentare in den Code, kurze Doku, dann wirds ins git geschoben.
Anschliessend fehlt dann noch Error handling der Heizung, sowie schreiben von Parametern.

[Apollo]

Hi,
es langt vollkommen wenn Ihr Marcus zu mir sagt. ;-)

Ach jetzt? Und ich soll dich immer mit "Gott" ansprechen .

Gruss

[2ndsky]

Plugin Pelletkessel

Sollte gehen, einfach das parent Item holen und mit parent.conf['eta_addr'] (oder wars config?) die Adresse auslesen.

[greentux]

[etatest]
    [[testuri]]
       eta_addr = 112/10021/0/0
       [[[strValue]]]
           type = str
           eta_key = 12000
       [[[unit]]]
           type = num
           eta_key = 12153

Bist Du Dir sicher, das ich dann im Item strValue tatsächlich Zugriff auf eta_addr habe?
Mein Beispiel sähe in wirklich ja so aus:

[etatest]
    [[testuri]]
       eta_addr = 112/10021/0/0/12000
       [[[strValue]]]
           type = str
           eta_key = unit
       [[[unit]]]
           type = str
           eta_key = value

Und im Plugin möchte ich nun für jeden der beiden Items (nix anderes ist die Schachtelung ja) die Werte von eta_addr holen und abhängig von eta_key den entsprechenden Wert zurückliefern.
Soweit ich den Test gestern Abend in Erinnerung habe, hatten wir dann keinen Zugriff auf eta_addr ...

[callidomus]

Hey,

natürlich kannst Du auch einen anderen key verwenden.
Das ist Dein Plugin.

Bis bald

Marcus

[greentux]

Also Differenzierung ggf nach einem anderen Key, wie eta_value_key = "unit" oder sowas wäre traumhaft. Nach type geht wohl aber auch...

Das hatten wir gestern probiert aber ggf. wars schon zu spät...

[callidomus]

Hi,

Na warten wir mal, was der Meister sagt

es langt vollkommen wenn Ihr Marcus zu mir sagt. ;-)


Zu der eigentlichen Frage- Problemstellung.
Wie die beiden Kollegen bereits angedeutet haben, sollte es keine Probleme geben.

[etatest]
    [[testuri]]
       eta_addr = 112/10021/0/0
       [[[strValue]]]
           type = str
           eta_key = 12000
       [[[unit]]]
           type = [COLOR="Red"]num[/COLOR]
           eta_key = 12153

Die uri würde ich dann im Plugin zusammensetzen und anhand des item types differenzieren.
Siehe auch mpd oder xbmc für das Handling.

Bis bald

Marcus

[Robert]

Wie kann man das mit dem Parser verhindern?

Hi! Nur genauso wie beim "ebus_type" auf Vorhandensein prüfen. Oder halt try/catch. Ich habe es nur gesagt, weil ich nicht sicher bin, ob wenn das parse_item in einem Plugin stirbt evtl. alle weiteren Plugins mitgerissen werden.

Grüße
Robert

[JuMi2006]

Das meinte ich ja ... das wäre doch so wie die von Dir vorgeschlagene Variante (jedes item erhält die uri und einen anderen eta_pu_type, braucht dann aber auch einen anderen namen) ?

Wie kann man das mit dem Parser verhindern?

[greentux]

Ja in EINEM Item habe ich auch verworfen... schon weils ja dann per KNX an 2 GAs gehen soll...

[Robert]

Vielleicht ist es schon zu spät - aber ich sehe da spontan kein "find_children" o.Ä. und du benutzt doch auch in EINEM Item "ebus_type" UND "ebus_cmd" (was übrigens, wenn mal nicht definiert, den Parser in den Abgrund reißt).

Grüße
Robert

[JuMi2006]

Übergeordnet find ich mittlerweile eleganter .. im eBus hab ich es ja auch mit get/set gemacht:

https://github.com/mknx/smarthome/bl...init__.py#L165

Dabei wird das dann später hier ausgewertet:

https://github.com/mknx/smarthome/bl...init__.py#L104

Übergeordnet spart halt doppelte Einträge in der config, ist aber vielleicht nicht intuitiv genug. Ich selbst hab noch große Probleme mit Python als "Objektsprache".

[greentux]

Mmmh, wir hatten das eigentlich vorhin genau so probiert und sh.py wollte es irgendwie nicht.
Gut, wenns gehen sollte, gehts da wohl morgen nochmal ran.

[Robert]

Das ist der Stand vom 3.1.!

Das geht beim Onewire seit 0.9 (also seit x Monaten? - kein Plan).

Zumal das ja nur von der Programmierung des Plugins abhängt. Wenn du dir den üblicherweise benutzten Plugin-Code mal anschaust siehst du, dass du eh "alle Items" zugeführt bekommst und anhand deines Attributes filterst. Da kannst du auch noch 10 weitere Attribute vergeben die du dann intern geeignet verwurschtelst.

/edit:

Mirko, dass braucht er nicht unbedingt. Einfach so wie in zig anderen Plugins ein zweites Attribut. Irgendwann will es nur einen Wert und will nicht "die Kinder suchen" etc. Einzig wenn eine URI wirklich viele Untertypen hat könnte das Sinn machen. Kann man sogar in meinem Squeezebox Plugin "bewundern": Übergeordnetes Item hält (optional) die MAC des Radios, die Childs haben aber auch sogar noch mehrere Attribute. Alles Zusammenrühren, fertig.