Featurewunsch: EnOcean plugin

[aschwith]

Hallo nochmal,

ich hab mich nochmal etwas schlau gemacht. Große Teile des Smartacknowledge und die Mailboxverwaltung sind anscheinend schon im TMC300 Chip, sprich dem Enocean Stick implementiert. Ich habe gerade eine erste Funktion set_smart_ack_learn_mode(on=1) ins plugin im Develop Zweig eingebaut. Vielleicht hilft Dir das weiter. Mit get_smart_ack_devices() kannst Du im interaktiven Modus die per Smartacknowledge eingelernten Devices abfragen, für die eine Mailbox angelegt wurde. Hier ist die Doku zum Protokoll:
https://www.enocean.com/.../EnOceanSerialProtocol3_V1.17.pdf

Viele Grüße
Alex

[Marcov]

vielen Dank - ich bin gerade beruflich eingespannt, habe aber am Wochenende Zeit und schaue es mir dann an!

[Marcov]

sorry, wo hast Du denn hingepusht, hier ist die letzte Änderungen 27 Tage her:
https://github.com/smarthomeNG/plugins/tree/develop

habs gefunden:
https://github.com/aschwith/plugins/...evelop/enocean

[Marcov]

Ich habe nun die Lernmodus im Interaktiven Modus gestartet und am Antrieb ausgelößt. Ich erhalte einen Fehler im Log,

2017-01-07 14:46:39 DEBUG    __init__     enocean      enocean: received header with data_length = 17 / opt_length = 0x00 / type = 4 -- __init__.py:run:327
2017-01-07 14:46:39 DEBUG    __init__     enocean      enocean: accepted package with type = 0x04 / len = 24 / data = [0x55, 0x00, 0x11, 0x00, 0x04, 0xd5, 0x02, 0x05, 0x00, 0x45, 0xa5, 0x20, 0x04, 0x00, 0x00, 0x80, 0xf5, 0xd9, 0x01, 0x93, 0xcd, 0x82, 0x00, 0xed]! -- __init__.py:run:335
Exception in thread enocean:
Traceback (most recent call last):
  File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
    self.run()
  File "/usr/local/smarthome_test/lib/plugin.py", line 114, in run
    self.plugin.run()
  File "/usr/local/smarthome_test/plugins/enocean/__init__.py", line 345, in run
    self._process_packet_type_event(data, optional)
  File "/usr/local/smarthome_test/plugins/enocean/__init__.py", line 144, in _process_packet_type_event
    if(event_code == CO_EVENT_SECUREDEVICES):
NameError: name 'CO_EVENT_SECUREDEVICES' is not defined 

muss es nicht "CO_RD_SECUREDEVICE" heißen? Auch wenn ich dies auskommentiere, gelingt mir das Anlernen nicht.

Bei dem Paket könnte es sich nun um die Anlernanfrage handeln:

									EEP					chip_id				sender_id				status	chck
55	0	11	00	d5	02	05	00	45	a5	20	04	00	00	00	80	f5	d9	01	93	cd	82	00	ed

Lern_REqeust.JPG
Nun müsste darauf ja die SA_LRN_ANSWER erfolgen sollte der Chip das Automatisch machen und dann auch entsprechend eine Mailbox anlegen? Oder muss ich diese Funktion selber bauen, bzw.

[aschwith]

Der Fehler war noch ein fehlendes Define im Plugin. Fixe ich im nächsten Pullrquest. Es handelt sich in der Tat um eine Anlernanfrage (vgl Enocean Serial Protokoll, Kapitel 1.9.4 Code 02: SA_CONFIRM_LEARN) Hier müsstest Du dich weiterhangeln.

PS: Ich stelle das Plugin übrigens gerade auf ein SmartPlugi für SmarthomeNG um.

VG

[Marcov]

hi, danke für die Antwort, den Fehler kann ich ignorieren und versuche nun die Antwort auf den Anlernbefehl zu senden? Ich verstehe nicht wofür die Funktion _process_packet_type_event da ist.

Das Kapitel 1.9.4. finde ich in diesem Dokument nicht:
https://www.enocean.com/fileadmin/re...col3_V1.17.pdf

meinst DU 1.10.4?

asdasd.JPG

Wenn ich das richtig sehe, dann ist das was ich nun im Log empfange, wenn ich den Lernmodus auslöse der SA_CONFIRM_LEARN (Tabele 14) vom Stelantrieb oder empfängt er sein eigenes Signal? Warum empfange ich das Signal nur, wenn der Lernmodus gestartet ist? Wenn er nicht gestartet ist, erhalte ich ein anderes Signal (sie meine Posts vorher)?

Wenn es von Aktor wäre, müsste ich diese Antwort senden (wobei ich nicht sicher bin, wie ich die zeit in MS auf zwei bits aufteile):
sh.enocean._send_packet(0x02,[0x00, 0x02, 0x26, 0x00])

dann erhalte ich im Log:

2017-01-07 21:31:21 WARNING  __init__     Main         enocean: sending packet with len = 11 / data = [0x55, 0x00, 0x04, 0x00, 0x02, 0xa5, 0x00, 0x02, 0x26, 0x00, 0xd7]! -- __init__.py:_send_packet:513
>>> 2017-01-07 21:31:22 DEBUG    __init__     enocean      enocean: received header with data_length = 1 / opt_length = 0x00 / type = 2 -- __init__.py:run:327
2017-01-07 21:31:22 DEBUG    __init__     enocean      enocean: accepted package with type = 0x02 / len = 8 / data = [0x55, 0x00, 0x01, 0x00, 0x02, 0x65, 0x02, 0x0e]! -- __init__.py:run:335
2017-01-07 21:31:22 INFO     __init__     enocean      enocean: Setting SmartAck mode returned code = NOT SUPPORTED -- __init__.py:_process_packet_type_response:284 

und was ist mit der Mailbox, regelt das der Chip selber? Oder generiert er auch die Antwort selber?

Ich habe die Befürchtung, dass das hier meine Fähigkeiten übersteigt und mir grundlegende Verständnis für die Funktionsweise des Plugins fehlen.

[aschwith]

Welchen Wert für die Zeit in ms willst Du den senden? 0x02 0x26 wäre 550ms. Warum der Stick die Antwort als "not supportet" beantwortet, weiß ich auch nicht. Schau mal, ob dein Controller Stick das SmartACK überhaupt unterstützt.

[Marcov]

Hi,

ja genau 550ms ist die maximale Antwortzeit, die man vereinbaren kann. Es schadet ja nicht, wenn ich diese hoch setze.

Nach einer Nacht Schlaf habe ich den Antrieb nun den Anlernbefehl hinbekommen:

    def set_smart_ack_learn_confirm_in(self):
        self._send_smart_ack_command(SA_WR_LEARNCONFIRM, [0x02, 0x26, 0x00, 0x00, 0x80, 0xf5, 0xd9, 0x01, 0x93, 0xCD, 0x82])
        logger.info("enocean:  smart ack write learn confirmation IN") 

diesen habe ich jetzt noch per Hand im Interaktiven Modus gesendet. Die letzen 4 bis sind die ID des Antriebs, davor kommt die ID des Controllers. Daraufhin wurde eine Mailbox eröffnet und der Antrieb zeigt die CHIP-ID des Controllers an. Diese Antwort versuche ich noch zu automatisieren, damit alle was davon haben.



Ich empfange bei Sollwertverstellung nun auch Daten, die aber anscheinend noch nicht richtig geparst werden. Ich empfange (komplett):

[0x55, 0x00, 0x0a, 0x07, 0x01, 0xeb, 0xa5, 0x53, 0x19, 0x6b, 0x0a, 0x01, 0x93, 0xcd, 0x82, 0x00, 0x01, 0xff, 0xff, 0xff, 0xff, 0x4c, 0x00, 0x00] 

Der "Payload" Bereich wird an den Parser gesendet und besteht aus 4 bits, in diesem Fall aus

[0x53, 0x19, 0x6b, 0x0a] 

Ist das so richtig? Im Parser wird dann nur dieser Bereich ausgewertet? Laut den Definitionen des A5_20_04 Telegrams (siehe Anhang) müsste das Telegram eine Länge von 32 haben, aber selbst das komplette Paket ist bei mir nur 24 bits lang und beinhaltet ja unter anderem noch die ID des Senders, passt also nicht zu dieser Definition: A5_20_04_1.JPG
. A5_20_04_2.JPG

[Marcov]

Da ich mit der Dokumentation nicht weitergekommen bin, habe ich mir den Parser noch mal angeschaut. Ich habe die Wertumrechnung überarbeitet:

results['TS'] = 10 + (payload[1]/255*20)
results['TMP'] = 10 + (payload[2]/255*20)
results['FT'] = 20 + (payload[1]/255*60)

Aber die Statusabfrage, ob es sich um die Solltemperatur oder den Stellwert handelt funktioniert auch nicht richtig, ich verstehe nicht, woher der Status genommen wird, vermutlich von einer falschen Stelle, denn dieser ist bei mir immer 0, dann kommen aber unplausible Werte heraus.
So geht es momentan, ist aber ne Krücke:

    def _parse_eep_A5_20_04(self, payload, status):
        # Status command from heating radiator valve, for example Hora smartdrive MX, RORG = 0x07
        logger.debug("enocean: processing A5_20_04")
        results = {}
        # current valve position 0-100%
        results['CP'] = payload[0]
        #Current feet temperature or setpoint
        if (payload[3]== 10):
                logger.debug("enocean: A5_20_04 sending Solltemperatur")
                results['TS'] = 10 + (payload[1]/255*20)
        elif (payload[3] == 8):
                logger.debug("enocean: A5_20_04 sending Vorlauftemperatur")
                results['FT'] = 20 + (payload[1]/255*60)
        results['TMP'] = 10 + (payload[2]/255*20)
        results['STATUS'] = payload[3]
        return results 

Wie hängt das nun mit dem obigen Dokument und den DB-Werten zusammen. Ich vermute:
DB3.7-3.0 ist Payload[0] = STellgröße des Antriebs,
DB2.7-DB2.0 ist Payload[1] = Solltemperatur oder Volrauftemperatur,
DB1.7-DB1.0 ist Payload[2] = Raumtemperatur,

DB0.7-DB0.0 ist Payload[3] -> hier benütige ich aber die einzelnen Positionen (DB01, DB02...DB0.7). Momentan weiß ich , wenn Payload[3]== 8, wird die Raumtemperatur ausgegeben, bei Payload[3]== 10 ist es die Solltemperatur (vermutlich weil DB0.1 dann = 1 und die Prüfsumme ebenfalls +1 , steigt der Wert um 2).

Also meine Frage: wie komme ich an die einzelnen DB0.X Datenpunkte?

Danke

[aschwith]

Deine Korrekturen im Decoder sind korrekt. Habe ich so übernommen. In der Statusabfrage war auch noch ein Fehler. Ich habe eben was committed. Bitte testen!
Gruß

[Marcov]

Danke! Schaue ich mir gleich an, im Sendebefehl habe ich auch noch was gefunden:

def send_radiator_valve(self,item, id_offset=0):
temperature = item 

dort muss es item statt item() heißen.

Weiter unten erhalte ich auch noch eine Fehlermeldung:

for sibling in return_children(item.parent): 

wirft bei mir einen error im Log "return_children" is undefined, habe aber noch keine Lösung hierfür.

Weißt Du, ob der Versand über die Mailbox automatisch erfolgt? Das funktioniert bei mir nämlich nicht. Also die Mailbox existiert, der Antrieb ist angelert, aber es wird nach dem Empfang von Daten nichts gesendet (zumindest ändert der Antrieb die Wert nicht). Der Befehl wird sofort gesendet, nachdem man den Wert ändert (zumindest erscheint das im Log so.

Man könnte ja im Parser für das EEP recht einfach den Sendebefehl aufrufen, ich hatte es aber so verstanden, dass der Chip die Mailbox selber verwaltet und die Werte dann auch sendet, wenn der Antrieb sich empfangsbereit zeigt.

[Marcov]

Ich habe nun mal testweise in die Funktion "_process_packet_type_radio" eine Abfrage eingebaut, ob es sich um die ID des Stellantriebs handelt um, daraufhin die Werte zu senden - das geht leider nicht, ich verstehe aber nicht genau warum.
Das Paket das Gesendet wird ist:

[0x55, 0x00, 0x0a, 0x00, 0x01, 0x80, 0xa5, 0x64, 0xd8, 0x06, 0x14, 0xff, 0xfa, 0xec, 0x80, 0x00, 0x8a] 

Der Databereich fängt bei 0x64 an (das ist 100 für die Ventilposition), d8 ist 216 (solltemperatur = 27 Grad), 0x06 ist DB 1, Binär = 110 (bit 7 = 0 (unused), bit 6 MC= Disable, bit 5-0 Wakupcycle = 1), 0x14 ist DB0, binär= 10100 (bit 7-6 = unused = 00, bit 5-4 DSO = 01 = 90 degree, bit 3 = 1= data, bit 2 = 0 (Button lock eingeschaltet), bit 1-0 = 00 (Service = no change).
Das scheint also erst mal richtig zu sein, trotzdem ändert sich im Stellantrieb nichts, kann es sein, dass es der falsche Telegramtyp ist? Laut Dokumentation ist das Adressing "unicast ADT" es müsste also noch die ID des Empfängers mitgesendet werden?:


ADT.JPG

[Marcov]

-

[Marcov]

Es läuft jetzt soweit, ich habe bei den Bits noch was ändern müssen, ich stelle alles ein, wenn ich es etwas getestet habe.

Ein wichtige Sache möchte ich noch ändern:

Wie rufe ich aus dem Parser eine Funktion in init.py auf?

edit: geht jetzt auch, ich teste es jetzt noch etwas

[beckerth]

Servus Jungs,

ich beschäftige mich auch mit dem Enocean Plugin und habe hier ein IBBCape mit KNX und einem Enocean Dimmaktor von Eltako am laufen. Der Dimmaktor ist ein FUD61NPN. Ließ sich nicht mit default Telegtamm einlernen, jedoch mit geändertem Telegramm:

   
def send_learn_dim(self, id_offset=0):
        if (id_offset < 0) or (id_offset > 127):
            self.logger.error("enocean: ID offset out of range (0-127). Aborting.")
            return
        self.logger.info("enocean: sending learn telegram for dim command")
        #self._send_radio_packet(id_offset, 0xA5, [0x02, 0x00, 0x00, 0x00])#standart Telegramm
        self._send_radio_packet(id_offset, 0xA5, [0xE0, 0x40, 0x0D, 0x80])#FUD61NPN

Jetzt würde ich versuchen das UTE mit VLD zu implementieren und dann das D2-01 Telegramm zu nutzen. Hintergrund: erstmal das Smartplug PSC234 von Permudo, später bräuchte ich dann den Zweifach-Aktor von NodOn. Aber erst mal eins nach dem anderen...
Beim UTE kann ich am Smartplug aufs Knöpfchen drücken - es sendet seine ID mit der Anfrage zum einlernen - dann müsste ich "nur" in 500ms passend antworten - siehe Screenshot.

Ich habe bereits gesehen das Marcov vermutlich schon die wichtigste Implementierung - antworten auf ein empfangenes Telegramm nach einigen hundert ms - bei sich lokal implementiert hat. Das UTE benötigt allerdings kein smart_ack. Gibt es den Code von Marcov irgendwo?

Soweit ich den Code bisher verstehe müsste das UTE eigentlich mit der _send_radio_packet() Funktion klappen da sie 4 Byte Payload + 3 Byte optional - vorrausgesetzt sie wird zur richtigen Zeit aufgerufen.

Was ich leider nicht verstehe:

CO_WR_LEARNMODE        = 0x23          # Function: Enables or disables learn mode of Controller.
CO_RD_LEARNMODE        = 0x24          # Function: Reads the learn-mode state of Controller.

Dazu finde ich in der Doku nichts - wäre vielleicht schon das was ich bräuchte..? Klingt zumindest so.

Danke für eure Unterstützung.

Grüße,
Tommi