Plugin Pelletkessel

[Robert]

Bin zwar nicht der Meister, aber verstehe das Problem aber auch nicht:

URI in zwei Items, zusätzlich (wie bei zig anderen Plugins) ein zweites eta_xxxxx was den Subtyp (oder was auch immer gemeint ist) selektiert. In der parse_item dann entsprechend einsortieren/speichern etc.?

[greentux]

Gleiche uri in zwei Items wie kurz oben angedeutet funktionierte nicht.
Thema bei 1wire auch hier
https://knx-user-forum.de/smarthome-...-sensoren.html

[JuMi2006]

Bleiben wir bei dem Beispiel:

[etatest]
    [[testuri]]
       eta_pu_uri = 112/10021/0/0/12000
       [[[strValue]]]
           eta_pu_type = strValue
           type = str
       [[[unit]]]
           eta_pu_type = unit
           type = str

Ich hab keinen Code im Kopf aber in Worten:

- in parse_item nach "eta_pu_type" suchen
- bei einem Treffer das parent suchen (hier: 112/10021/0/0/12000)
- jetzt eta_pu_uri im plugin mit eta_pu_type verküpfen
- im plugin dann die uri auslesen und je nachdem wieviele childs (eta_pu_type) es gibt eben unterschiedlich verarbeiten

[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.

[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.

[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".

[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

[greentux]

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

[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?

[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

[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

[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]

Hey,

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

Bis bald

Marcus

[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 ...

[2ndsky]

Plugin Pelletkessel

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