Test Adapter EnOcean (2) v0.3.x

[pgBroker]

@jey-cee heute mal wieder die neueste Version von deinem Adapter vom GitHub installiert und mit meinen Sorgenkindern FAH60b ausprobiert.

Und ich traue kaum meinen Augen. Da stehen plötzlich brauchbare Luxwerte im Adapter. Jabadabado!!!

Gönne dir ein Bier, Spende ist unterwegs.

[IOBaer]

Ich habe leider noch Probleme beim Anlernen der FSR14-2x und -4x. Bevor ich dazu komme:

Ist es normal, dass "CMD" nach dem Absenden eines Befehls immer auf "Bestätigt: false" (also rot) bleibt?

[Jey Cee]

@iobaer Ja das ist normal, sollte aber nicht so sein. Ist schon geändert.

[Schrubbel]

Hi, so mein Stick und die Fenstergriffsensoren sind nun da und ich wollte grade mal anlernen.
Der Adapter ist grün und er sieht auch die ID des Sonsors.
Nur leider habe ich diese Fehlermeldungen im Log und das Anlernen klappt nicht.
Was kann ich tun?

host.ioBroker	2021-02-10 16:03:38.733	info	Restart adapter system.adapter.enocean.0 because enabled
host.ioBroker	2021-02-10 16:03:38.732	error	instance system.adapter.enocean.0 terminated with code 6 (UNCAUGHT_EXCEPTION)
enocean.0	2021-02-10 16:03:38.113	info	(17857) The serial port was closed.
enocean.0	2021-02-10 16:03:38.108	warn	(17857) Terminated (UNCAUGHT_EXCEPTION): Without reason
enocean.0	2021-02-10 16:03:38.107	info	(17857) terminating
enocean.0	2021-02-10 16:03:38.106	info	(17857) cleaned everything up...
enocean.0	2021-02-10 16:03:38.087	error	(17857) Cannot read property 'rorg_number' of undefined
enocean.0	2021-02-10 16:03:38.086	error	(17857) TypeError: Cannot read property 'rorg_number' of undefined at handleType1.main (/opt/iobroker/node_modules/iobroker.enocean/lib/tools/Packet_handler.js:63:28)
enocean.0	2021-02-10 16:03:38.085	error	(17857) unhandled promise rejection: Cannot read property 'rorg_number' of undefined
enocean.0	2021-02-10 16:03:38.084	error	(17857) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
enocean.0	2021-02-10 16:03:38.005	warn	(17857) State "enocean.0.0593c0ad.rssi" has no existing object, this might lead to an error in future versions
enocean.0	2021-02-10 16:03:14.104	info	(17857) ["/dev/ttyACM0","/dev/ttyUSB0"]
enocean.0	2021-02-10 16:03:12.549	info	(17857) starting. Version 0.3.2 in /opt/iobroker/node_modules/iobroker.enocean, node: v12.20.1, js-controller: 3.2.16

Danke!

[Jey Cee]

@schrubbel sagte in Test Adapter EnOcean (2) v0.3.x:

Was kann ich tun?

Installier mal neu, sollte gefixt sein.

[IOBaer]

@jey-cee Danke Dir.

Habe ein paar Punkte - alle beziehen sich auf die Adapter-Version 0.3.2:

1. Empfiehlst Du bei Steuerungen über Blockly eigentlich den "steuere"- oder den "aktualisiere"-Baustein? Funktionieren tut beides. Wenn Du die Ack-Funktion noch hinbiegst, wird die bessere Wahl wohl definitiv "steure" sein.

2. Wenn ich z.B. in einem Blockly-Skript 7 Aktuatoren hintereinander schalten lasse, verschluckt er mir einige Befehle, d.h. führt sie nicht aus. Mit einem Delay von jeweils 500 ms klappt es aber. Ich könnte mir vorstellen, dass das kein Bug ist. Ggf ändert sich das ja auch, sobald die Ack-Funktionalität von Dir korrigiert ist.

3. Hauptsächliches Problem ist, dass ich Schwierigkeiten hatte, die FSR14-2x und -4x anzulernen. Er kommt da mit den Sender-IDs teilweise vollständig durcheinander. Ebenfalls wird die Base-ID immer weiter fortgeschrieben (13, 14, 15 ...). Ich konnte mir nun selbst helfen, indem ich manuell unter "Objekt bearbeiten" (dort bei Nativ oder RAW) die Base-ID auf die Nummer des jeweiligen Kanals (also beim 2x: 1 oder 2 und beim 4x 1, 2, 3 oder 4) gestetzt habe und die Sender-ID ebenfalls anpasste. Die Sender-ID kam dann natürlich via PCT14 in die ID-Tabelle der Funktionsgruppe 2. Auch war ein Teach- In oftmals nicht möglich bzw. nicht erforderlich.

Hoffe, die Rückmeldung hilft. Vielen Dank für Dein tolles Engagement!

[Schrubbel]

@jey-cee

Super Geil, nun funktioniert es! Jetzt brauch ich nur noch längerer Schrauben.

Ein Danke kommt gleich per PayPal.

[mane444]

Hi, ich hab gerade meine vier Dimmer FUD61NPN vom Testsystem ins Livesystem übertragen.
Adapter installiert, Objekte vom Testsystem ins Livesystem kopiert, den Stick eingesteckt und im Adapter angewählt.
Läuft! Dachte nicht das das so einfach geht.
Nun kann ich meinen FHEM abschalten.
Super Arbeit, danke für den Adapter.

[Jey Cee]

@iobaer sagte in Test Adapter EnOcean (2) v0.3.x:

1. Empfiehlst Du bei Steuerungen über Blockly eigentlich den "steuere"- oder den "aktualisiere"-Baustein? Funktionieren tut beides. Wenn Du die Ack-Funktion noch hinbiegst, wird die bessere Wahl wohl definitiv "steure" sein.

Da ich mich mit Blockly bisher sehr wenig auseinander gestzt habe, kann ich nichts Empfehlen.

@iobaer sagte in Test Adapter EnOcean (2) v0.3.x:

2. Wenn ich z.B. in einem Blockly-Skript 7 Aktuatoren hintereinander schalten lasse, verschluckt er mir einige Befehle, d.h. führt sie nicht aus. Mit einem Delay von jeweils 500 ms klappt es aber. Ich könnte mir vorstellen, dass das kein Bug ist. Ggf ändert sich das ja auch, sobald die Ack-Funktionalität von Dir korrigiert ist.

Hm ein richtiger Bug ist das nicht, aber trotzdem sollte das nicht passieren. Das schau ich mir an.
EDIT: Es ist doch ein Bug.

@iobaer sagte in Test Adapter EnOcean (2) v0.3.x:

3. Hauptsächliches Problem ist, dass ich Schwierigkeiten hatte, die FSR14-2x und -4x anzulernen. Er kommt da mit den Sender-IDs teilweise vollständig durcheinander. Ebenfalls wird die Base-ID immer weiter fortgeschrieben (13, 14, 15 ...). Ich konnte mir nun selbst helfen, indem ich manuell unter "Objekt bearbeiten" (dort bei Nativ oder RAW) die Base-ID auf die Nummer des jeweiligen Kanals (also beim 2x: 1 oder 2 und beim 4x 1, 2, 3 oder 4) gestetzt habe und die Sender-ID ebenfalls anpasste.

Hier müssen wir kurz die Begrifflichkeiten klären:

• Base ID = USB Stick (ID von ioBroker)
• Sender ID = gleich die ID mit der ein Befehl von ioBroker gesendet wird
• ID = die ID vom Gerät das gesteuert werden soll oder Daten Empfangen werden

Leider weis ich mit deiner Schilderung so nichts an zu fangen.

Die Sender-ID kam dann natürlich via PCT14 in die ID-Tabelle der Funktionsgruppe 2. Auch war ein Teach- In oftmals nicht möglich bzw. nicht erforderlich.

Ja wenn man mit PCT14 arbeitet braucht es kein Teachin, da muss ich den Text noch anpassen.

[IOBaer]

@jey-cee Danke Dir!

Wäre wie gesagt klasse, wenn das mit dem ACK-irgendwann noch klappen würde.

Zu meiner Schilderung, mit der Du nichts anfangen konntest:
Ich habe gerade z.B. einen FSR14-4x über das Adaper-Interface angelegt. Ich kann den Wert "baseIDoffset" nicht im Interface setzen (wie das z.B. in einem älteren Video von Dir noch ging), sondern nur nachträglich über den Objekte-Baum. Für den gerade genannten FSR14-4x hat er automatisch die baseIDoffset 17 hinterlegt. Soll das so sein? Habe sie dann manuell auf die Nummer des Kanals gesetzt. Funktionieren tut nun alles (bis auf das mit dem ACK, wie oben geschrieben - aber das is ja für die Funktion nicht wichtig).

Ja, die Begrifflichkeiten waren mir klar.

Legt der Adapter eigentlich außer in der Ordnerstruktur in ioBroker ("Objekte"), also unterhalb von "enocean.ZAHL" bzw. "system.adapter.enocean.ZAHL" noch wo Einstellungen ab?

[Jey Cee]

@iobaer sagte in Test Adapter EnOcean (2) v0.3.x:

Für den gerade genannten FSR14-4x hat er automatisch die baseIDoffset 17 hinterlegt. Soll das so sein?

Ja das muss so sein, Geräte die nicht Unterscheiden ob ein Telegram für sie ist oder nicht müssen mit einer eigenen Sender ID angesprochen werden. Diese Zahl spielt aber keine große Rolle mehr, die wurde durch Sender ID ersetzt.
Wenn bei dir durch das ändern dieser Zahl das Gerät jetzt reagiert, hast du wohl eine ältere Version installiert.

@iobaer sagte in Test Adapter EnOcean (2) v0.3.x:

Legt der Adapter eigentlich außer in der Ordnerstruktur in ioBroker ("Objekte"), also unterhalb von "enocean.ZAHL" bzw. "system.adapter.enocean.ZAHL" noch wo Einstellungen ab?

Nein, warum frägst du?

[IOBaer]

@jey-cee bei mir steht:

Installierte Version: 0.3.2
Installierte Instanzen: 1

Sollte also doch eigentlich passen? Ich habe immer die Instanz(en) gelöscht, dann den Adapter, dann mit dem bekannten Github-Link den Adapter eingespielt und dann die Instanz generiert.

Die Frage nach den Speicherorten war nur, weil ich wissen wollte, ob er sich sowas die die Offset-Zählung im Hintergrund sonst wo merkt.

Du hattest oben geschrieben, dass das mit der ACK-Bestätigung schon geändert sei. Ist es dann normal, dass es bei mir noch nicht klappt mit dieser Adapter-Version?

Danke

Edit: die ID der Eltako-Geräte habe ich jeweils durch Abhören ermittelt, d.h. lastID mitgelogged.

[Jey Cee]

@iobaer sagte in Test Adapter EnOcean (2) v0.3.x:

Sollte also doch eigentlich passen?

Ja.

@iobaer sagte in Test Adapter EnOcean (2) v0.3.x:

Du hattest oben geschrieben, dass das mit der ACK-Bestätigung schon geändert sei. Ist es dann normal, dass es bei mir noch nicht klappt mit dieser Adapter-Version?

Ja wenn du sie seit ich das geschrieben hab nicht neu installiert hast.

[IOBaer]

@jey-cee Danke. Kann ich die irgendwie neu installieren / aktualisieren, ohne alles neu einrichten zu müssen? ggf. über JSON-Export und anschließenden Import?

Habe oben noch einen Edit hinzugefügt.

[mustang]

@jey-cee @IOBaer
mit dem gleichzeitigen ansteuern mehrerer Aktoren hatte ich das gleiche Verhalten, daß nicht alle Befehle ausgeführt wurden. Ich kann allerdings auch nicht mehr sagen, ob wirklich alle gesendet wurden, bin aber der Meinung dem war so.
Also eher ein Problem bei den Empfängern, wenn zuviel Funksignale auf einmal rausgehen. Habe es im Script ebenso über einen Zeitversatz (hier 1sec je Aktor) gelöst und bin damit zufrieden.

[Jey Cee]

@iobaer einfach drüber installieren ohne die Objekte zu löschen.

@mustang sagte in Test Adapter EnOcean (2) v0.3.x:

Also eher ein Problem bei den Empfängern, wenn zuviel Funksignale auf einmal rausgehen.

Ne liegt schon auf der Adapter Seite, er versucht alles auf einmal zu senden. Er wartet nicht bis der Vorherige befehl abgesendet wurde.

[IOBaer]

@jey-cee Danke, das hat perfekt geklappt. Ist das so normal, dass nach einem Befehl das Ack-Flag lediglich gesetzt wird (ggf. wird auch geprüft, ob gesendet wurde), das aber keine echte Rückmeldung ist, ob der Befehl am Eltako-Bus ankam?

Ich habe testweise den Bus spannungsfrei geschaltet und einen Befehl über ioBroker abgesetzt - "Bestätigt: true" steht dann dennoch dort, obwohl der Befehl natürlich nicht angekommen sein kann.

[Jey Cee]

@iobaer der Adapter kriegt nur eine Rückmeldung vom Stick ob der den Befehl angenommen hat. Angesichts der Tatsache das Befehl nicht gesendet werden scheint das auch keine Garantie zu sein ob er den Befehl auch sendet.

Die EnOcean Geräte senden keine Bestätigung ob sie einen Befehl erhalten haben. Je nach Gerät wird der Status als Antwort zurück gesendet.

Letztlich ist das Ack Flag die Bestätigung das der Adapter den Befehl ausgeführt hat.

[IOBaer]

@jey-cee Danke für die Antwort, das dachte ich mir - jetzt habe ich Gewissheit. Letztlich kann man als Antwort ja z.B. die Relais-Änderung auswerten.

[pgBroker]

Noch ein paar Dinge zur Einbindung des FAH60B ...

Wie die Daten vom Sensor umgesetzt werden steht in der Datei TF-13-10.json:

{
    "eep": "TF-13-10",
    "rorg_number": "0xA5",
    "telegram": "4BS",
    "func_number": "0x00",
    "type_number": "0x00",
    "type_title": "Brightness sensor 0-50 Lux & 300-30000 Lux",
    "case": [
        {
            "condition": {
                "range": {
                    "bitoffs": "8",
                    "bitsize": "8",
                    "value": {"==": [{"var": "value"}, 0]}
                }
            },
            "datafield": [
                {
                    "data": "Illumination",
                    "shortcut": "ILL",
                    "bitoffs": "0",
                    "bitsize": "8",
                    "iobroker": {
                        "role": "value.brightness",
                        "type": "number",
                        "read": true,
                        "write": false,
                        "unit": "lx"
                    },
                    "value": { "var": "value" },
                    "decimals": 0
                }
            ]
        },
        {
            "condition": {
                "range": {
                    "bitoffs": "8",
                    "bitsize": "8",
                    "value": {">=": [{"var": "value"}, 1]}
                }
            },
            "datafield": [
                {
                    "data": "Illumination",
                    "shortcut": "ILL",
                    "bitoffs": "8",
                    "bitsize": "8",
                    "iobroker": {
                        "role": "value.brightness",
                        "type": "number",
                        "read": true,
                        "write": false,
                        "unit": "lx"
                    },
                    "value": {
                        "+": [
                            {
                                "*": [
                                    {
                                        "-": [
                                            {
                                                "var": "value"
                                            },
                                            1
                                        ]
                                    },
                                    116.92913
                                ]
                            },
                            300
                        ]
                    },
                    "decimals": 0
                }
            ]
        }
    ]
}

Wenn ich es richtig verstehe, verwendest du bei 0-50 lux den Wert direkt, bei 300-30000 lux den Wert multipliziert mit 116,92913 + 300.

Im Datenblatt zum FAH60B steht aber:

FAH-Modus:
Lerntelegramm: 0x18080D80 Datentelegramm nach EEP: A5-06-01 Data_byte3 = Helligkeit 0-50 lux, linear n = 0x00-0x64
(nur gültig wenn DB2 = 0x00) Data_byte2 = Helligkeit 300-30.000 lux, linear n = 0x00-0xFF
Data_byte1 = -
Data_byte0 = 0x08

D.h. bei 0-50 lux musst du den Wert durch 2 teilen und nicht direkt verwenden.

Mir ist das aufgefallen, weil ich im Grafana-Plot fein abgestufte Werte im Bereich 0 bis 100 lux sehe, danach die größeren Sprünge (117 lux Abstände). Das sollte aber nur im Bereich 0 bis 50 lux so sein.

Seltsam ist dann noch, dass der ILL Datenpunkt im ioBroker mit 5 Nachkommastellen ausgegeben wird, was sinnfrei ist, wenn die Auflösung nur 117 lux beträgt.

Im json Objekt steht "decimals": 0 in beiden Fällen. Warum wird das bei der Ausgabe nicht berücksichtigt?