Test Adapter EnOcean (2) v0.3.x

[mustang]

@jey-cee
ja sicher, wie vorgegeben..., deshalb fing die BaseID ja auch wieder mit 1 an.

[Jey Cee]

@mustang ich frag nur weil die Sender ID keinen Sinn ergibt, die darf nur 8 stellen haben. Bei dir hat die aber 12.
Sieht das bei allen so aus?

[mustang]

@jey-cee
habe erst mal nur mit zwei Rolladenaktoren getestet. Erst habe ich einen als TF61J und den zweiten als FTA65J eingelernt. Dann als ich feststellte, daß beide reagieren, den FTA65J als TF61J eingelernt - allerdings mit gleichem Ergebnis. Mehr wollte ich erstmal nicht zurücksetzen, damit ich auf meine alte Version 0.3.0 wieder scheller zurück kann - mit der lief es ja.

[Jey Cee]

@mustang wie sieht denn das raw vom Gateway aus? Von dort holt er sich die Base ID, vielleicht stimmt die da schon nicht.

[mustang]

@jey-cee

{
  "_id": "enocean.0.gateway",
  "type": "device",
  "common": {
    "role": "",
    "name": "Gateway",
    "type": "string",
    "read": true,
    "write": false
  },
  "native": {
    "BaseID": "ffea0e00",
    "Frequency": "868.3 Mhz",
    "Protocol": "ERP1",
    "AppVersion": "2.15.0.0",
    "ApiVersion": "2.6.9.0",
    "ChipID": "058cd41c",
    "ChipVersion": "454f0103",
    "AppDescription": "GATEWAYCTRL",
    "BaseID_offset": 3
  },
  "from": "system.adapter.enocean.0",
  "ts": 1611833954841,
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  },
  "user": "system.user.admin"
}

[mustang]

@jey-cee
hab nochmal ein Rollback auf die 0.3.0 gemacht - so sieht das sent-Kommando dort aus:

enocean.0	2021-01-28 17:45:17.377	debug	(253924) Sent data: 55000a0701eba501000208ffea0e0c000005937ce2ff0000

und das Raw des Aktors:

{
  "type": "device",
  "common": {
    "name": "Blind actuator"
  },
  "native": {
    "id": "05937ce2",
    "eep": [
      "TF-01-01",
      "F6-02-02"
    ],
    "manufacturer": "ELTAKO",
    "baseIDoffset": 12
  },
  "from": "system.adapter.enocean.0",
  "user": "system.user.admin",
  "ts": 1611129886011,
  "_id": "enocean.0.05937ce2",
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

[Jey Cee]

@mustang es ist ganz klar das Problem ist die Sender ID, aber es ist völlig unklar weshalb sie falsch ist.
Egal mit was ich die Funktion füttere bekomme ich kein so komisches Ergebnis. Aber die Sender ID wird nur beim Anlernen erzeugt und dann nie wieder geschrieben.
Deswegen hab ich auch nach dem raw für Gateway gefragt, weil ich dachte die Base ID muss schon falsch sein.

Für den Moment weis ich nicht weiter. Danke fürs Testen und die Infos.

[mustang]

@jey-cee
ja gern. Du hast den neuen Parameter "Sender_ID" eingefügt. Vorher wurde die ja im Hintergrund aus der BaseID des Gateway und dem "baseIDoffset" gebildet. Da muß es ja irgendwie haken, daß er jetzt eine zwölfstellige Sender_ID bildet.
Gib bitte Bescheid, wenn ich weiterhelfen kann und vielen Dank für deine hervorragende Arbeit soweit.
Ich lass die beiden Aktoren jetzt erstmal auf Version 0.3.1, dann kann ich schneller wieder damit weitertesten falls erforderlich (die fehlerhafte Version 0.3.1 ist gesichert).

[TheAriba]

@mustang vielen Dank für die Erklärung. Woher weißt du dann auf welcher Position der Rollladen steht? Bzw. wie bekommt man mit dass und vorallem wie lokal geschalten wurde? Puh da habe ich bestimmt was vor der Brust mit der yahka Integration :D.

@Jey-Cee irgendwie bekomme ich meinen Tf61L nicht eingelernt. An was kann das denn liegen?

enocean.0	2021-01-28 16:24:18.643	debug	2
enocean.0	2021-01-28 16:24:18.643	debug	(7416) 55000707017af670050070f53000ffffffff4d00
enocean.0	2021-01-28 16:24:18.275	debug	(7416) 55000707017af600feee578c2000ffffffff4000
enocean.0	2021-01-28 16:24:18.116	debug	(7416) 55000707017af670feee578c3000ffffffff3d00
enocean.0	2021-01-28 16:24:16.148	debug	(7416) 55000707017af600feee578c2000ffffffff4100
enocean.0	2021-01-28 16:24:13.908	debug	(7416) 55000707017af650050070f53100ffffffff4c00
enocean.0	2021-01-28 16:24:13.380	debug	(7416) 55000707017af670feee578c3000ffffffff4000
enocean.0	2021-01-28 16:24:13.156	debug	(7416) 55000707017af600feee578c2000ffffffff4100
enocean.0	2021-01-28 16:24:12.932	debug	(7416) 55000707017af670feee578c3000ffffffff4100
enocean.0	2021-01-28 16:24:12.708	debug	(7416) 55000707017af600feee578c2000ffffffff4100
enocean.0	2021-01-28 16:24:12.484	debug	(7416) 55000707017af670feee578c3000ffffffff4100
enocean.0	2021-01-28 16:24:12.228	debug	(7416) 55000707017af600feee578c2000ffffffff4100
enocean.0	2021-01-28 16:24:12.037	debug	(7416) 55000707017af670feee578c3000ffffffff4000
enocean.0	2021-01-28 16:24:07.110	debug	(7416) 55000707017ad5090582dde40000ffffffff4d00
enocean.0	2021-01-28 16:24:01.047	debug	(7416) 55000707017af600feee578c2000ffffffff4100
enocean.0	2021-01-28 16:23:59.015	debug	(7416) 55000707017af650050070f53100ffffffff4d00
enocean.0	2021-01-28 16:23:58.487	debug	(7416) 55000707017af670feee578c3000ffffffff4100
enocean.0	2021-01-28 16:23:58.279	debug	(7416) 55000707017af600feee578c2000ffffffff4300
enocean.0	2021-01-28 16:23:58.055	debug	(7416) 55000707017af670feee578c3000ffffffff4100
enocean.0	2021-01-28 16:23:57.831	debug	(7416) 55000707017af600feee578c2000ffffffff4300
enocean.0	2021-01-28 16:23:57.623	debug	(7416) 55000707017af670feee578c3000ffffffff4100
enocean.0	2021-01-28 16:23:57.383	debug	(7416) 55000707017af600feee578c2000ffffffff4300
enocean.0	2021-01-28 16:23:57.191	debug	(7416) 55000707017af670feee578c3000ffffffff4100
enocean.0	2021-01-28 16:23:56.935	debug	(7416) 55000707017af600feee578c2000ffffffff4100
enocean.0	2021-01-28 16:23:56.791	debug	(7416) 55000707017af670feee578c3000ffffffff4100
enocean.0	2021-01-28 16:23:55.052	debug	(7416) sendTo "autodetect" to system.adapter.admin.0 from system.adapter.enocean.0
enocean.0	2021-01-28 16:23:31.214	debug	(7416) sendTo "getEEPList" to system.adapter.admin.0 from system.adapter.enocean.0
enocean.0	2021-01-28 16:23:31.210	debug	(7416) sendTo "getDevices" to system.adapter.admin.0 from system.adapter.enocean.0
enocean.0	2021-01-28 16:23:31.206	debug	(7416) sendTo "listSerial" to system.adapter.admin.0 from system.adapter.enocean.0
enocean.0	2021-01-28 16:23:31.204	info	(7416) ["/dev/ttyAMA0","/dev/ttyUSB0"]
enocean.0	2021-01-28 16:23:30.429	debug	(7416) Packet type 2 received: 02
enocean.0	2021-01-28 16:23:30.428	debug	(7416) 5500050102db00ffef62000a
enocean.0	2021-01-28 16:23:30.413	debug	(7416) Sent data: 5500010005700838
enocean.0	2021-01-28 16:23:30.413	debug	(7416) Packet type 2 received: 02
enocean.0	2021-01-28 16:23:30.412	debug	(7416) 5500030002b3000100
enocean.0	2021-01-28 16:23:30.406	debug	(7416) Sent data: 55000100057025fb
enocean.0	2021-01-28 16:23:30.399	debug	(7416) Packet type 2 received: 02
enocean.0	2021-01-28 16:23:30

[TheAriba]

Kann ich euch irgendwie beim Testing unterstützen? (Möchte mir aber nur ungern etwas zerschiessen da ich jetzt fast alle Geräte in iobroker drin habe.)

[mustang]

@jey-cee
hab noch mal kurz die Version 0.3.1 wieder aktiviert und den FWS61 eingelernt - da sieht das dann richtig aus - hier das RAW:

{
  "type": "device",
  "common": {
    "name": "FWS61"
  },
  "native": {
    "id": "058dda99",
    "eep": [
      "TF-13-01"
    ],
    "manufacturer": "ELTAKO",
    "Sender_ID": "ffea0e04",
    "baseIDoffset": 4
  },
  "from": "system.adapter.enocean.0",
  "user": "system.user.admin",
  "ts": 1611856807627,
  "_id": "enocean.0.058dda99",
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

@EnoceanEltako
im Moment fahre ich immer komplett Zu/Auf nach unterschiedlichen zeitlichen Bedingungen. Wenn lokal manuell geschaltet wird und der Rollladen dann irgendwo dazwischen hängt, sehe ich nur am Status, daß er er weder ganz offen noch ganz geschlossen ist. Perspektivisch soll es bei mir so laufen, daß nach Helligkeit einige Rollläden auf eine bestimmte Höhe gefahren werden, welche dann durch die per Script vorgegebene Fahrzeit gesteuert wird.
Das ganze lebt nun mal von Scripten zur Automatisierung, sonst macht es für mich keinen Sinn.
Ganz auf oder zu mach ich von der Bedingung abhängig, ob die Position schon erreicht ist (B0/BI). Da ist es mir egal wo der Rollladen momentan hängt.

[Jey Cee]

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

@Jey-Cee irgendwie bekomme ich meinen Tf61L nicht eingelernt. An was kann das denn liegen?

Also soweit ich das im Log sehen kann, scheint es als gibt es 2 Probleme.
Zum einen scheint der Anlernvorgang nicht gestartet worden zu sein.
Und zum anderen sendet der Aktor kein Teachin Telegram, was dafür spricht das der Aktor auch nicht im Anlernmodus ist.
Kann es sein das du den Aktor in den Anlrenmodus versetzt hast bevor du im Adapter den Anlernmodus aktiviert hast?

[TheAriba]

@jey-cee hatte die Reihenfolge eigentlich eingehalten. Versuche es morgen mal nochmal.
@mustang ok interessant, verstehe ich. Naja im Grunde fahre ich morgens die Rollläden hoch und abends auf einen gewissen Wert runter. Also 100% zu machen wir sie in der Regel nicht sondern lassen ein paar Spalten offen. Bspw. Stehen auf manchen Fensterbänken bei uns auch Blumen so dass das komplette herunterfahren nicht geht.
Muss mich mal demnächst damit beschäftigen. Wird heavy

[jhpaulsen]

@jey-cee funktioniert der Nodon rollershutter denn jetzt problemlos? Falls dem so wäre würde ich von Hass wieder zum ioBroker zurückgehen

[mustang]

@Jey-Cee

Hallo - ich mach noch mal die Baustelle FWS61 auf. Habe mir die Sensortelegramme nochmal angeschaut und festgestellt, daß Telegrammteil 1 falsch ausgewertet wird. Hier mein Beispiel an dem ich das nachvollzogen habe:

enocean.0	2021-01-29 11:50:03.074	debug	(265027) Message for ID 058dda99 has been received.
enocean.0	2021-01-29 11:50:03.071	debug	(265027) 55000a0701eba5ff7d001a058dda990000ffffffff3d00
enocean.0	2021-01-29 11:49:43.705	debug	(265027) Message for ID 058dda99 has been received.
enocean.0	2021-01-29 11:49:43.703	debug	(265027) 55000a0701eba500030128058dda990000ffffffff3d00

so werden die Werte im Objekt ausgegeben:

CMD state   Command ID      state   state               Teach-in(0)	
DWS state   Dawn sensor     state   value.brightness    251.0824 lx	
RAN state   Rain            state   switch              false	
SNE state   Sun East        state   value.brightness    0.5882 klx	
SNS state   Sun South       state   value.brightness    1.7645999999999997 klx	
SNW state   Sun West        state   value.brightness    0 klx	
TMP state   Temperature     state   value.temperature   18.83 °C	
WND state   Wind speed      state   value.battery       70.00 V	
rssi    state  Signal Strength	state	value.rssi     -61 dBm

das ist meine Umrechnung laut der Eltako Sensor-Telegramm-Tabelle für den FWS61:

Telegrammteil 1
Wert    ist(eig.Berechn.)   Ausgabe in iobroker
ff      255(=1000lx)        251,08
7d      125(=18,82°C)      18,83
00      0                  70,00
1a      true(=Regen)       false

Telegrammteil 2
00      0                   0
03      3(1,7647klx)       1,7646
01      1(0,5882klx)       0,5882
28      statisch

Dabei ist die Ausgabe für Dämmerungswert, Windgeschwindigkeit und Regen falsch, bei den anderen sind es ja teilweise nur im hinteren Kommabereich Rundungsabweichungen, welche nicht relevant sind.

Ich habe den FWS61 jetzt mit der Konfig aus Version 0.3.1 in der Version 0.3.0 manuell angelegt - die Werte sind gleich.

[mustang]

@jey-cee
gute Neuigkeiten: Habe nochmal die Version 0.3.1 installiert (hat mir einfach keine Ruhe gelassen, zumal Du ja auch keinen Fehler finden konntest).
Vorgehensweise von mir war diesmal jedoch etwas anders:

• alle Objekte gelöscht
• Version 0.3.0 deinstalliert
• ioBroker gestoppt (neu)
• ioBroker gestartet (neu)
• Version 0.3.1 installiert
• Instanz erzeugt und neue Geräte eingelernt

Beispiel (Raw) eines Aktors:

{
  "type": "device",
  "common": {
    "name": "Blind actuator"
  },
  "native": {
    "id": "0584ab89",
    "eep": [
      "TF-01-01",
      "F6-02-02"
    ],
    "manufacturer": "ELTAKO",
    "Sender_ID": "ffea0e03",
    "baseIDoffset": 3
  },
  "from": "system.adapter.enocean.0",
  "user": "system.user.admin",
  "ts": 1612017314872,
  "_id": "enocean.0.0584ab89",
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Bin jetzt beim dritten Aktor - und es funktioniert. Für meine Installation wäre jetzt momentan nur noch das Fehlerbild des FWS61 offen.
Also ioBroker stoppen/starten hat vielleicht die entscheidende Änderung des Verhaltens bewirkt. Eventuell war doch noch was im Hintergrund, daß sich bei der Software was unplausibel verhalten hat...

[Jey Cee]

@mustang Jetzt warst du etwas zu schnell, ich hab gerade noch den FWS61 gefixt.

[Jey Cee]

@jhpaulsen Am besten du testest es vorher mit einem und entscheidest dann selsbt.

[mustang]

@jey-cee
Top - habe eben noch ein Update der Version 0.3.1 gemacht - der FWS61 sieht jetzt auch gut aus.
Vielen Dank und demnächst läuft bei Dir auch noch mal eine Spende ein...
Ist es schon absehbar wann es eine finale Version geben wird, wo ich dann vielleicht ein vorerst letztes mal eine komplette Neuinstallation machen müßte?

[Jey Cee]

@mustang schwer ab zu schätzen, letztlich hängt das davon ab ob noch jemand Gravierende Fehler findet.
Aktuell würde ich sagen in 3 Monaten kann man darüber Nachdenken.

Bei den Geräten könnte es auch noch Änderungen geben, in der Form das die Befehle vereinfacht werden oder Objekte dazu/weg kommen. Das kann ich aber nur mit entsprechendem Feedback machen, weil ich selber die Geräte ja nicht in Benutzung hab. Dadurch sehe ich nicht an welcher stelle man optimieren kann.