Featurewunsch: EnOcean plugin

[JuMi2006]

Hallo Robert, grundsätzlich verstanden, aber ein zwei Fragen dazu noch :

-> "item-ref" wäre das smarthome-item ?

-> "if not item.conf['enocean_rorg'][3] == frame[5]:" Wozu das "[3]"? Diese Liste ist mir unklar.

-> "if (item.conf['enocean_rorg'] in my_dict) and (item.conf['enocean_id'] in my_dict[item.conf['enocean_rorg']]):" Woher kommt denn jetzt rorg? Ich hab ja nur den Anfang der RORG im Telegramm. Hier blick ich nicht ganz durch.

-> "pl = frame[4:]" Payload variiert ja in den einzelnen RORGs auch noch, müsste man also schon vorher aussortieren/bereitstellen.

Puh .. für mich als Python Anfänger echt harter Tobak.

[JuMi2006]

Im Grunde würde doch folgendes reichen, was den Code insgesamt länger aber übersichtlicher macht. Die angegeben Positionen sind jetzt mal Fantasie-Positionen.

my_id_dict = {'0x00':'header[3:8]','0X01':'header[4:9]'}
my_items_dict = {'mac_as_str_or_bytes':[item-ref],'2nd mac':[item2-ref, item3-ref]}
my_payload_dict = {'F6-02-02':'data[4:5]','F6-02-3':'data[4:6]}
my_value_dict = {'F6_02_02':{'A1':'pl & (1<<4) == (1<<4)','A0':'pl & (1<<5) == (1<<5)'}, 'F6_02_03':{'foo':'foo_transform'}}

Bevor wir irgendwas machen sortieren wir den Typ aus dem Header. Damit erhalten wir die Sender ID. Bei RADIO (0x01) ist ja zumindest die Sender-ID immer an einer fixen Stelle. Damit wird erstmal geprüft ob die Sender-ID in my_items_dict ist. Wenn nicht dann können wir hier gleich aufhören.

Ist die Sender-ID in my_items_dict dann kann man die items durchlaufen und schauen wo payload laut rorg-id liegt. Die haben wir ja aus dem item und checken die mit my_payload_dict.

Was haben wir bislang:
-Sender-ID -> O.K.
-RORG -> O.K.
-Payload korrekt bestimmt -> O.K.

Fehlt also noch die Information was wir mit der Payload machen. Dafür nehmen wir dann my_value_dict.

Eigentlich das gleiche was Du vor hast, nur dass ich das was ich hier geschrieben habe verstanden habe . Und modular bleiben wir damit auch.

Grüße

[Robert]

my_id_dict = {'0x00':'header[3:8]','0X01':'header[4:9]'}
my_items_dict = {'mac_as_str_or_bytes':[item-ref],'2nd mac':[item2-ref, item3-ref]}
my_payload_dict = {'F6-02-02':'data[4:5]','F6-02-3':'data[4:6]}
my_value_dict = {'F6_02_02':{'A1':'pl & (1<<4) == (1<<4)','A0':'pl & (1<<5) == (1<<5)'}, 'F6_02_03':{'foo':'foo_transform'}}

Eigentlich das gleiche was Du vor hast, nur dass ich das was ich hier geschrieben habe verstanden habe . Und modular bleiben wir damit auch.

Ja, stimmt.

Einzig würde ich dir wirklich ans Herz legen, 'my_payload_dict' und 'my_value_dict' zusammenzufassen. Sonst müsste man die auf Konsistenz prüfen etc. Einfach eine weitere dict-Ebene anlegen. Kann man ja übersichtlich schreiben:

my_value_dict = {'F6_02_02':
                      {'payload_idx':range(4,6),
                       'entities':
                            {'A1':'pl & (1<<4) == (1<<4)',
                             'A0':'pl & (1<<5) == (1<<5)',
                            },
                      },
                 'F6_02_03':
                      {'payload_idx':range(4,7),
                       'entities':
                            {'foo':'foo_transform',
                            },
                       'sonder':'locke',
                      },
                } 

So geschrieben macht doch das Hinzufügen neuer EEPs richtig Spass! ;-)

Zudem: So kann man auch ein neues key-value-Paar anlegen falls man das mal braucht - sonst bräuchte es da immer mehr direkte dicts die auch noch alle die gleichen keys haben.

Achtung: Ich habe die Indexierung des Payloads von String auf eine normale Nummernfolge umgestellt. Dann kannst du den Payload mit
frame[my_value_dict[rorg]['payload_idx']] direkt ohne eval lesen!

Grüße
Robert

[JuMi2006]

Ja so macht das Freude
Ich denke ich kann am Wochenende was funktionierendes ins develop schieben. Da kann man dann weiter dran feilen.

[JuMi2006]

Ging schneller als befürchtet aber doch langsamer als gedacht. Ich hab jetzt mal was in develop geschoben. Das sollte ne Grundlage sein.

@Robert:
Ich habe den Payload bei eval belassen, das hat den Vorteil dass man beim späteren eval der Werte auch Daten aus anderen Variablen nutzen kann, ich denke dann z.B. an "opt_data".

Was noch fehlt ist wohl ein sauberes Threading und die entsprechenden Exception. Ich würde drum bitten vorerst die Menge der Kommentare und "print" Befehle nicht zu löschen, das kann unheimlich beim debuggen helfen. Später kann man das gerne auf die Log-Ebene reduzieren. Die ersten Lichter konnte ich schonmal schalten ... cooles Erlebnis. Ansonsten ist natürlich jeder zum Verbessern und testen eingeladen. Die Doku folgt dann die Tage. Hier mal meine Beispiel Konfigurationen:

etc/plugin.conf

[enocean]
    class_name = EnOcean
    class_path = plugins.enocean
    serialport = /dev/ttyUSB0

items/enocean.conf

[A1]
type = bool
enforce_updates = true
enocean_id = 00:22:60:37
enocean_rorg = F6_02_02
enocean_value = A1
knx_send = 1/2/10
knx_listen = 1/2/11
knx_dpt = 1

[A0]
type = bool
enforce_updates = true
enocean_id = 00:22:60:37
enocean_rorg = F6_02_02
enocean_value = A0

[B1]
type = bool
enforce_updates = true
enocean_id = 00:22:60:37
enocean_rorg = F6_02_02
enocean_value = B1

[B0]
type = bool
enforce_updates = true
enocean_id = 00:22:60:37
enocean_rorg = F6_02_02
enocean_value = B0

[A0B0]
type = bool
enforce_updates = true
enocean_id = 00:22:60:37
enocean_rorg = F6_02_02
enocean_value = A0B0

https://github.com/mknx/smarthome/bl...an/__init__.py

Grüße

[jonah64]

... hier gibt es ja einiges neues, Prima!!!
Danke sehr schonmal an Robert und JuMi2006.
Gerne beteilige ich mich bei Tests und Feedback soweit es meine Zeit zuläßt.
D.h. für mich: zügig eine Umgebung dafür aufbauen, verstehen was Ihr so getrieben habt und den Code installieren, bevor die freien Tage vorbei sind....

Gruss Jonah

[jonah64]

@kuala: Bin Dir noch eine Antwort schuldig; hier eine Kurzbeschreibung meiner Lösung mit FHEM:
Ich werte mit meiner Lösung den Festerstatus aus. Dazu nutze ich FHEM als Gateway zwischen EnOcean und KNX.
D.h. Ich definiere in FHEM ein Macro, in dem ich den Fensterstatus auf KNX-Werte konvertiere.
Der Wert wird also auf den KNX-Bus geleitet, alles andere mache ich dann (bisher) über linknx-Logic und Anzeige in Smartvisu

Hier mal ein Ausschnitt aus meiner Datei fhem.cfg:

define TCM310_0 TCM 310 /dev/ttyUSB0@57600
define EO_DG_Fensterstatus EnOcean 00123456
attr EO_DG_Fensterstatus subType switch

define DG_Bibo_Terrassentuer_Status EIB 2/4/54
attr DG_Bibo_Terrassentuer_Status model dpt5

define L_DGTerassentuerZu notify EO_DG_Fensterstatus {\
my $r1 = $value{"EO_DG_Fensterstatus"};;;;\
if (($r1 eq 'open') || ($r1 eq "open from tilted")) {\
 fhem('set DG_Bibo_Terrassentuer_Status value 10');;\
} else {\
  if ($r1 eq "closed" ) {\
   fhem('set DG_Bibo_Terrassentuer_Status value 0');;\
   } else {\
     if ($r1 eq "tilted") {\
       fhem('set DG_Bibo_Terrassentuer_Status value 20');;\
     }\
   }\
 }\
}

Noch eins:Ich benutze die Werte 0|10|20 für geschlossen|offen|gekippt.
Ursprünglich wollte ich KNX mit den Werten 0|128|255 befüllen, was mir irgendwie lieber gewesen wäre. Allerdings ist es mir nicht gelungen, m.V. hat FHEM da noch Bugs (Version Stand vom vergangenen März, 5.3 glaube ich)

Gruss Jonah

[JuMi2006]

D.h. für mich: zügig eine Umgebung dafür aufbauen, verstehen was Ihr so getrieben habt und den Code installieren, bevor die freien Tage vorbei sind....

Was für Hardware hast Du denn?

[jonah64]

Alles was ich bisher habe ist:
Hoppe Secusignal Fenstergriff
und
TCM310 USB Stick

[JuMi2006]

Der hat 8 Stati die sich aus der "letzten Bewegung" ergeben.
Ich würde das folgendermaßen (Anhand der Himmelsrichtungen) implementieren:

oben nach links: enocean_value = nw (north to west)
oben nach rechts: enocean_value = ne (north to east)
links nach oben: enocean_value = wn (west to north)
links nach unten: enocean_value = ws (west to south)
rechts nach oben: enocean_value = en (east to north)
rechts nach unten: enocean_value = es (east to south)
unten nach links: enocean_value = sw (south to west)
unten nach rechts: enocean_value = se (south to east)

Aktualisierung des items dann nur wenn die entsprechende Bedingung (enocean_value) True ist.

Quelle:https://www.google.de/url?sa=t&rct=j...58187178,d.Yms

[jonah64]

...wenn man genau schaut gibt es eigentlich nur 3 Möglichkeiten, da Werte doppelt vergeben wurden. Manche Bits sind ja auch nicht belegt. Damit wird es wesentlich einfacher als Du vorschlägst.

Bei der Stellung 0b11X0XXXX (Fenster geöffnet) kann man bei meinen Griffen auch das X auswerten. ("öffnen" und "öffnen aus gekippt heraus") Damit wären das 4 auswertbare Stellungen. Wobei, die Information "öffnen aus gekippt" heraus ist nicht wirklich interessant für mich. Ich denke es reicht, wenn man sich auf die 3 spezifizierten Stellungen beschränkt.

Momentan sieht die Konfiguration bei mir so aus:
item:

[EnOcean]
    [[Fenster]]
    type = num
    enforce_updates = true
#    enocean_id = 00:22:60:37
    enocean_id = 00:12:5A:F6
#    enocean_rorg = F6_02_02
    enocean_rorg = F6_10_00
    enocean_value = VAL
    sqlite = yes

im Plugin habe ich

RADIO_PAYLOAD_VALUE ergänzt:
            'F6_10_00':{'payload_idx':'data[1]',
                'entities':{
                    'VAL':'pl & 0xf0'
                },},

und was soll ich sagen, es funktioniert!

Also noch übergebe ich die 4 Stellungen an das Item, werde ich aber noch ändern denke ich, wird nur die Logic des entitys noch bischen komplexer.
Die 4 nicht definierten Bits (zweite Nibble) habe ich zu 0 gemappt wie man sieht.

Aktualisierung des items dann nur wenn die entsprechende Bedingung (enocean_value) True ist.

Ich musste erstmal länger überlegen, was Du mit diesem Satz meinst. Ich möchte doch keinen Bool-Wert an das Item übergeben sondern den Wert.

Aber jetzt verstehe ich: Du würdest die ganzen enocean_values einzeln festlegen und entsprechend viele boolsche Items definieren. Das finde ich nicht so praktisch.
Alternativ könnte man beide Wege definieren, was meint Ihr?


Also insgesamt ging der Aufbau viel schneller, als ich gedacht hätte.

[peterf]

Hallo,

Mal meine 2 Cent zu den Hoppe Fenstergriffen:
Das geöffnet ist als Wert nicht eindeutig. Soll heissen, es kann systembedingt den einen oder anderen Wert haben.
Ich habe hier mehrere Fenstergriffe und bei einigen wollte das nicht klappen mit dem Status und da habe ich die mal aufgemacht. Der eigentliche Schalter wird jede Viertel-Umdrehung geschaltet, incl. Piezoladung. Dass gekippt (oben) und geschlossen (unten) wird durch einen zusätzlichen Reedkontakt unterschieden. Das klappt zuverlässig. Aber bei geöffnet von gekippt und geöffnet von geschlossen klappt das nicht immer. Da ist der Reedkontakt manchmal offen, manchmal geschlossen. Liegt wohl an der Toleranz.
Also sollte man einen Wert für gekippt, einen für geschlossen und die beiden anderen für geöffnet haben.

Gruß, Peter.

[JuMi2006]

Ich würde schon alle 8 Varianten einbauen ... man denke an "liegende" Fenster und dann links/rechts angeschlagen, aber ich kenne die Teile nicht aus dem wirklichen Leben.

Ich musste erstmal länger überlegen, was Du mit diesem Satz meinst. Ich möchte doch keinen Bool-Wert an das Item übergeben sondern den Wert.

Aber jetzt verstehe ich: Du würdest die ganzen enocean_values einzeln festlegen und entsprechend viele boolsche Items definieren. Das finde ich nicht so praktisch.

Naja der Wert sagt zwar was über den Griff aus, aber noch nix über den Zustand des Fensters, daher halte ich das für recht sinnvoll. Kann man aber drüber diskutieren. Das Problem kommt wenn andere Zustände plötzlich False werden. Das hatte mich beim Schalter beschäftigt. Während A1 "True" wurde, ist auf B1 trotzdem ein "False" gesendet worden ... stimmt auch, aber macht keinen Sinn. Die Auswertung des Wertes findet damit im Plugin und nicht im Item statt. Du müsstest jetzt den Bit-Wert wieder im Item zum Zustand machen, könntest aber gleich die items gekippt/geschlossen/offen als Bool-Wert haben ... Geschmackssache.

[Robert]

Mal von der Diskussion, ob man jetzt lieber Zahlenwert oder Bool hat:

Geil (sic!), dass man so schnell ein neues Gerät unterstützen kann!?

Zur Diskussion - auch wenn ich momentan keine Sensoren habe:

Warum sollen die anderen Entitäten nicht auch ein "False" bekommen? Ohne "force_updates" passiert da doch eh nix. Es ist halt ein neuer Schwung an Infos aufgetaucht. Zudem: Das gibt ne Sonderlocke - woanders wird man froh sein, wenn z.B. der Verschlußsensor sein "False" mal wiederholt.

Was den Fenstergriff angeht: Vielleicht lese ich das EEP gerade falsch, aber hier würde ich auch eher 3 Bool-Entitäten sehen, welche vielleict wirklich mit "N"/"OW"/"S" zu benennen werden, aus eben dem von Mirko genannten Grund der Einbaulage. Zudem gibt es "Dreh-Vor-Kipp" Beschläge (habe ich z.B. teilweise), die geöffnet/gekippt vertauschen. Das Schöne: eine weitere numerische Entität die die Zustände 0-1-2 hat kostet nix extra außer einer Zeile. Ausgewertet wird ja nur wenn auch ein entsprechendes Item vorhanden ist.

Bin gespannt was der nächste unterstützte Sensor wird!

Grüße
Robert

[jonah64]

@peterf:

Da ist der Reedkontakt manchmal offen, manchmal geschlossen. Liegt wohl an der Toleranz.
Also sollte man einen Wert für gekippt, einen für geschlossen und die beiden anderen für geöffnet haben.

...Das habe ich zwar noch nicht beobachtet, aber deckt sich ja mit meiner Meinung, dass man nur 3 Stellungen zurückgibt.

Ich neige dazu dem Gesagten von Robert und Mirko zuzustimmen. Vielleicht ist bool doch besser. Und wie Robert sagt, auch numerischer Wert kostet nicht viel. Ich werde mal beides einbauen und damit experimentieren. Beim "Status" vom RTR gibt es ja auch mehrere Möglichkeiten der Realisierung. Also vielleicht N,OW,S und NUM.