Test Adapter EnOcean v0.3.x
-
Da muss ich dich enttäuschen.
-
Hallo Jey Cee,
erstmal herzlichen Dank für deine bisherige Arbeit. Ich selbst versuche mich gerade mit ioBroker da ich meine vorhandene FHEM Lösung ersetzen will. Die Gründe sind einfach dass ich mit NodeJS und Javascript besser zurechtkomme als mit Perl.
Ich habe aktuell folgende Sensoren und Aktoren von Eltako:
12 x FT55-wg (das sind Piezo Taster)
12 x FSB61NP-230V (das sind Rolladenaktoren)
Ich will meine Ausstattung auf Smarte Rauchmelder, Fenstergriff Sensoren und Heizungsaktoren erweitern. Nur Eltako wird mir auf die Dauer einfach zu teuer. Um verschiedene Hersteller und Standard zu unterstützen will ich nun auf ioBroker wechseln. Es sollen mittelfristig günstigere Anbieter wie Homematic ergänzt werden. Aber zunächst will ich meine vorhandenen Devices übernehmen.
Wie alles begann.
Meine ursprüngliche Lösung war rein Eltako (komplett gekauft), so habe ich auch den Shuttle Wand PC mit der Eltako Software. Da diese aber nur Eltako unterstützt wurde diese von mir dann durch FHEM ersetzt und das habe ich so nun auf dem Shuttle seit knapp 1 Jahr am laufen. Ich wollte das nur erwähnen um darzustellen dass ich keinen Raspberry nutze. (Es wird ja oft auf den PI verwiesen im Zusammenhang mit ioBroker.
So sieht FHEM aktuell bei mir aus (ohne Dashboard):
~~https://snag.gy/RqvlFJ.jpg" />Man sieht die Aktoren, Taster und die zwei Timer für Morgens und Abends. Ist also alles noch ganz simple.
Ich bin ein Anfänger also entschuldigt wenn ich die Begrifflichkeiten noch nicht so draufhabe, ich bin noch am lernen.
Kommuniziert wird über einen USB300 Gateway Stick:
~~https://snag.gy/ZVWHyG.jpg" />Nun habe ich auf dem Shuttle zusätzlich ioBroker installiert und auch deinen Adapter zum laufen bekommen:
~~https://snag.gy/k3YDNz.jpg" />Ich glaube dass auch der Connect zu dem USB Stick erfolgreich ist:
~~https://snag.gy/5ar2x6.jpg" />
~~https://snag.gy/IYxRh0.jpg" />Nun würde es ans einlernen gehen.
Bevor ich jedoch nun versuche einzulernen habe ich mir mal die unterstützen Hersteller angesehen und festgestellt dass meine Aktoren und Taster noch nicht in der Liste sind, wobei der FRW komischerweise die Taster EEP in eurer Liste aufweist, müsste es nicht eigentlich 'F6-05-01 sein anstelle von F6-02-01 ? (https://www.enocean-alliance.org/wp-con … public.pdf
https://github.com/Jey-Cee/ioBroker.eno ... er_list.js
https://github.com/Jey-Cee/ioBroker.eno ... vices.json
Die Details meiner zwei Devices sind...
FSB61NP:
EEP: A5-3F-7F
manufID: 00D
model: FSB61
FT55:
EEP: F6-02-01
manufID: 7FF
Ich kenne mich wie gesagt nicht so dolle aus und weiß nicht ob das wissenswert ist. Hier habe ich weitere EEP Details die ich damals für FHEM verwendet habe um meine Devices einzulernen: https://www.enocean-alliance.org/wp-con ... public.pdf
So und nun zum eigentlichen Kern meiner Anfrage
Ich würde hier gerne soweit ich kann unterstützen und es wäre toll wenn ihr mir sagen könntet wie ich beginnen könnte um diese zwei Devices in euer Coding aufzunehmen? Ich habe ein wenig Bastelerfahrung mit NodeJS und daher ein wenig JS coden. Hatte mal ein kleinesTool geschrieben für ein Computerspiel mit MongoDB, es war ein kleines Gildenportal mit Schnittstellen zu einer REST-API. Aber Vorsicht, ich bin kein Profi und meine Kenntnisse reichen nur für Spaghetti-Code. Aber vielleicht kann ich ja damit den Stein ins Rollen bringen und ein Experte schaut dann drüber und macht es hübsch
Ich bräuchte aber einen Tipp wo ich im Code einsteigen könnte und wie das Project aufgebaut ist. Es reicht vermutlich nicht einfach eine A5-3F-7F.js im eep Ordner anzulegen. Kann mir jemand bei diesem Einstieg helfen bevor ich über Stunden hinweg den ganzen Code lesen und verstehen muss. Mir würde reichen wenn mir einer erklären könnte welche Code-Files alle zu chekcen wären für ein Device, dann würde ich mir die vorhanden mal anschauen.
Weiterhin habe eine Frage zur Übernahme der Daten von FHEM:
FHEM und ioBroker laufen ja auf der gleichen Maschine und nutzen das gleiche Gateway. Meine naive Vorstellung ist nun dass die Aktoren und Taster im Gateway eingelernt sind (die müssen sich gegenseitig kennen?). Sprich, ich müsste doch für ioBroker nicht mehr alles neu einlernen oder, das Gateway und die Aktoren reden ja schon miteinander?
Ich will mir das ersparen da vor allem in den Bädern/WC die Aktoren 'hinter' den Steckdosen sitzen damit wir die Fliesen nicht beschädigen mussten. Daher ist ein erneutes Einlernen wirklich mit etwas Arbeit verbunden, die Steckdosen müssen raus und ein Kabelgefummel in der kleinen Öffnung bis ich an die Drehregler des Aktors rankomme um das Einlernen zu aktivieren. Ich hoffe daher dass ich irgendwie über ein manuelles einfügen der Devices (ohne einlernen) einfach die vorhandene Konfiguration nutzen könnte. Wäre das aus eurer Sicht möglich ?
Wäre es möglich wenn man die Stellen in FHEM kennt eine Art Migrationstool zu bauen der einem die Devices ausliest und in ioBroker überträgt. Ich frage jetzt nicht an ob ihr das bauen könnt sondern ob es realistisch wäre und ich würde mich da versuchen einzuarbeiten. Wenn ihr aber aus eurer Erfahrung sagt, dass es technisch nicht möglich ist dann spare ich mich das suchen
Grüße, Michael~~~~~~~~~~
-
Also ich ich habe mal Testweise einen Taster im Büro mit Auto Detect eingelernt:
~~https://snag.gy/lhdX0y.jpg" />und die Werte kommen an:
~~https://snag.gy/F95g8j.jpg" />nun werde ich mal versuchen anhand der IDs in FHEM einen anderen Taster manuell zu übernehmen ohne einzulernen.~~~~
-
das manuelle eintragen funktioniert nur halb.
Hier wie der zweite Taster aussieht den ich manuell ergänzt habe:
~~https://snag.gy/95DSUM.jpg" />Oben ist der erkannte und unten der manuell eingefügte.
~~https://snag.gy/057spN.jpg" />Im Log sieht man den Unterschied, der automatisch erkannte sende Werte. Der manuelle scheinbar nicht.
Anbei auch ein Bild der Objekte:
~~https://snag.gy/FSOsyP.jpg" />Interessant ist, dass zwar die Werte der Tasten leer sind aber der rssi Wert gesetzt wird. Ich glaube das war die Signalstärke.
Grüße, Michael~~~~~~
-
Hallo Michael,
es freut mich das du hier Unterstützen willst.
wobei der FRW komischerweise die Taster EEP in eurer Liste aufweist, müsste es nicht eigentlich 'F6-05-01 sein anstelle von F6-02-01 ? ` Ne die EEP passt schon, das hat der Hersteller so festgelegt. Keine Ahnung warum die nicht F6-05-01 verwenden, eventuell verwenden die ein fertiges Modul mit F6-02-01 und haben den FRW drum rum gebaut.
Der FT55 ist eigentlich ein PTM2xx Modul und wird als generisches Gerät unterstützt, wie du schon herausgefunden hast.
Beim FSB61NP ist das ganze nicht ganz so einfach, bisher geht eigentlich nur daten Empfangen. Daten senden hab ich zwar Grundlegend eingebaut, aber da fehlt noch etwas an Logik für die Geräte. Das heisst hier gibt es noch keine Referenz wie das funktioniert.
Es reicht vermutlich nicht einfach eine A5-3F-7F.js im eep Ordner anzulegen. ` Doch fast. Ich versuch es mal zu erklären:
-EEP2IOB.json definiert die Objekte die für ein Profil angelegt werden
-z.B. "A5-3F-7F.js" hier werden die Funktionen hinterlegt für das Auswerten der Daten und den Bau der Datentelegramme die gesendet werden sollen
-devices.json hier sind die Geräte mit Infos wie Hersteller, Model, EEP(s) und Type hinterlegt.
-eepInclude.js fast alle EEP files zusammen und stellt sie im Adapter zur Verfügung
Meine naive Vorstellung ist nun dass die Aktoren und Taster im Gateway eingelernt sind (die müssen sich gegenseitig kennen?). Sprich, ich müsste doch für ioBroker nicht mehr alles neu einlernen oder, das Gateway und die Aktoren reden ja schon miteinander? ` Nein dafür ist die Software verantwortlich, FHEM oder eben enOcean Adapter. Manuelles Anlernen ist kein Problem, hast du ja schon gefunden.
Wäre es möglich wenn man die Stellen in FHEM kennt eine Art Migrationstool zu bauen der einem die Devices ausliest und in ioBroker überträgt. Ich frage jetzt nicht an ob ihr das bauen könnt sondern ob es realistisch wäre und ich würde mich da versuchen einzuarbeiten. Wenn ihr aber aus eurer Erfahrung sagt, dass es technisch nicht möglich ist dann spare ich mich das suchen
`
Das sollte schon machbar sein, aber ob sich der Aufwand lohnt kann ich nicht abschätzen.das manuelle eintragen funktioniert nur halb. ` Da scheint ein Bug zu sein. Als Workaround, wähle bei Hersteller Enocean GmbH und als device PTM200, dann gehts.
-
Vielen Dank Jey Cee,
ich werde mich mal die Tage damit befassen und mal schauen ob ich den FSB61NP zunächst mal auslesen kann. Muss mich aber erstmal in das Protokoll einlesen und schauen ob ich bei mir lokal ändern kann.
Dein Adapter liegt hier schätze ich bei mir auf der Installation:
/opt/iobroker/node_modules/iobroker.enocean $ ls -l insgesamt 252 drwxr-xr-x 4 iobroker iobroker 4096 Dez 30 17:48 admin -rw-r--r-- 1 iobroker iobroker 664 Dez 21 09:42 appveyor.yml drwxr-xr-x 5 iobroker iobroker 4096 Dez 30 17:48 docs drwxr-xr-x 2 iobroker iobroker 4096 Dez 30 17:48 eep -rw-r--r-- 1 iobroker iobroker 16013 Dez 21 09:42 gulpfile.js -rw-r--r-- 1 iobroker iobroker 15066 Dez 21 09:42 io-package.json drwxr-xr-x 2 iobroker iobroker 4096 Dez 30 17:48 lib -rw-r--r-- 1 iobroker iobroker 1093 Dez 21 09:42 LICENSE -rwxr-xr-x 1 iobroker iobroker 33728 Dez 21 09:42 main.js drwxr-xr-x 153 iobroker iobroker 4096 Dez 30 17:50 node_modules -rw-r--r-- 1 iobroker iobroker 1924 Dez 30 17:48 package.json -rw-r--r-- 1 iobroker iobroker 135122 Dez 30 17:50 package-lock.json drwxr-xr-x 2 iobroker iobroker 4096 Dez 30 17:48 parser -rw-r--r-- 1 iobroker iobroker 2537 Dez 21 09:42 README.md drwxr-xr-x 3 iobroker iobroker 4096 Dez 30 17:48 test -rw-r--r-- 1 iobroker iobroker 4776 Dez 21 09:42 tsconfig.jsonIch bin jetzt auch kein GIT Benutzer und werde mal schauen ob es das zunächst einfach mal lokal ändern kann (natürlich mit Sicherheitskopie). In GIT muss ich mich dann einlesen.
Grüße, Michael
-
@Jey Cee:das manuelle eintragen funktioniert nur halb.
Da scheint ein Bug zu sein. Als Workaround, wähle bei Hersteller Enocean GmbH und als device PTM200, dann gehts.Stimmt, mit dem PTM 200 funktioniert es.
Grüße, Michael
-
Hi Jey Cee,
ich habe mich mal mit dem Protokoll beschäftigt und anhand des vorhandenen Codes für den PTM200 Taster in f6-02-01.js und dem Internet Versucht das Protokoll zu verstehen.
Bitte schau mal ob das alles so richtig ist, ich poste es hier mal als Referenz dass nicht jeder der seinen Aktor integrieren will so viel suchen muss. Wenn es zu viel ist, bescheid geben dann lösche ich es.
Aufbau der EEP Profile:
https://blog.protocolbench.org/2016/05/ … -telegram/
und
https://www.enocean-alliance.org/wp-con ... public.pdf
Hier mal grafisch dargestellt:
~~https://snag.gy/zu9lgO.jpg" />-> der interessante Teil ist blau und Lila
Schauen wir uns den Blauen Teil genauer an.
Wie oben im Link beschrieben unterteilt man die Daten in Telegramm Typen, sogenannte RORG. Siehe dazu im Link Kapitel 1.4. Im ersten Databyte wird der Telegramtyp festgelegt. es gibt diese hier:
Typ RORG ORG COMMENT RPS f6 05 Repeated Switch Com. 1BS d5 1 Byte Communication 4BS a5 07 4 Byte Comminucation VLD d2 Variable Length Data MSC d1 Manufacture Specific C. ... ... ... ...-> wir werden sehen wir benötigen nur RPS und 4BS für die Taster (FT55) und den Aktor (FSB61NP)
Im Kaptiel 1.6.1 und 1.6.2 finden wir die Details zu den Telegramm Typen
~~https://snag.gy/NGnZoS.jpg" /><size size="150">Beispiel 1: Taster nach unten gedrückt: 55000707017af610feff5e0c3003ffffffff3d00</size>
~~https://snag.gy/O6gymX.jpg" />Der interessante Teil ist nun der Status und der Data Payload des blauen Bereiches.
Wiederum entnehmen wir dem EnOcean PDF in Kapitel 2 beim Taster F6-02 die Deatils wie sich die Daten aufbauen
Der Taster scheint zwei Message Arten zu haben die durch das Statusfeld unterschieden werden. Es gibt eine Message wenn T21 und NU gleich '1' sind und eine andere Message wenn T21 zwar '1' ist aber NU gleich '0'
Im Feld Status sehen wir in der Binäransicht dass Bit 4 und 5 eine '1' haben daher schauen wir uns dazu das Format der Daten an.
Der Aufbau ist wie folgt (für Status 30 also T21 = 1 und NU = 1):
~~https://snag.gy/gfJNrv.jpg" />AI pressed -> 0x10 A0 pressed -> 0x30 BI pressed -> 0x50 B0 pressed -> 0x70Second Action habe ich leider nicht verstanden, eventuell haben die meine Taster nicht
<size size="150">Beispiel 2: Taster losgelassen: 55000707017af600feff5e0c2003ffffffff3c00</size>
~~https://snag.gy/wSkAmD.jpg" />Der Unterschied zum ersten Beispiel ist nun der Status 20 und dass die Daten 00 sind. Damit ist das der zweite Message Typ und den schauen wir uns nun an.
Der Aufbau ist wie folgt (für Status 20 also T21 = 1 und NU = 0):
~~https://snag.gy/y3OJAK.jpg" />-> in unserem Fall also no button (0x00)
-> Vermutung hier werden sozusagen alle 4 Taster auf den Initialwert '0' gesetzt ?
<size size="150">Beispiel 3: Aktor reagiert: 55000a0701eba5000e010a0183e5230003ffffffff5300</size>
~~https://snag.gy/Me9OvA.jpg" />Die erste Auffälligkeit die Data Länge ist nun von 7 auf 10 angewachsen.
Die zweite Auffälligkeit RORG ist nicht mehr RPS sonder BS4 und hat daher 4 Datenbytes (also daher die 3 neuen Felder)
Um uns den Datenanteil anzuschauen gibt es nun ein Problem unser EEP ist hier A5-3F-7F und das ist ein Universal Typ, sprich es gibt im EnOcean Profiles PDF von oben keine genauen Daten. Jeder Hersteller kann hier machen was er will.
Daher nehmen wir uns die Eltako Spec zu Hand: https://www.eltako.com/fileadmin/downlo … ow_res.pdf
Auf Kapitel T-13 finden wir die Spec.
~~https://snag.gy/hmJion.jpg" />-> der Aktor fuhr also 1,4 sec nach oben und erreichte nicht seine Endposition
<size size="150">Beispiel 4: Message an Aktor zum hochfahren: 55000707017af6010183e5233003ffffffff5500</size>
~~https://snag.gy/WZLQ9o.jpg" />Schauen wir uns die Daten an:
-> 0x01
Kaptiel T-13
https://www.eltako.com/fileadmin/downlo … ow_res.pdf
Data_byte3 = 0x70 = Endlage Oben, 0x50 = Endlage unten, 0x01 = Start auf, 0x02 = Start ab
-> es war also das Signal zum hochfahren das passt: 0x01
Das wars erstmal.
Grüße, Michael~~~~~~~~~~~~~~~~~~
-
ich will als nächstens nun mal die Status Messages für den FSB61NP auswerten, das Senden geht ja noch nicht und dazu habe ich in deinem Coding folgende Zeilen gefunden. Dazu will ich die f6-01-01.js nehmen und auf den Aktor anpassen. Aber leider verstehe ich eine von dir genutzte Schreibweise nicht.
const T21 = (telegram.status & T21_FLAG) === T21_FLAG; const NU = (telegram.status & NU_FLAG) === NU_FLAG;….
const R1 = (dataField & 0xE0) >> 5; const R2 = (dataField & 0x0E) >> 1; const EB = ((dataField & 0x10) === 0x10);Ich verstehe diese Schreibweise leider nicht.
Ich nehme an, dass hinter dem & die Bit-Position im Byte steht dass dich interessiert, oder (dataField & 0x0E für bit 1-3)?
Der zweite Teil der Zeile macht mir noch mehr Probleme, '===' kenne ich eigentlich als Typenvergleich, was bedeutet das hier?
Ebenfalls '>>', das ist bitweises verschieden oder?
Grüße, Michael
-
Der zweite Teil der Zeile macht mir noch mehr Probleme, '===' kenne ich eigentlich als Typenvergleich, was bedeutet das hier? ` Es handelt sich tatsächlich um einen Typen vergleich, das Ergebnis ist dann true oder false.
Ebenfalls '>>', das ist bitweises verschieden oder? ` Ja, das ist eine Bitwise operation. Es werden von links so viele Nullen nach geschoben wie rechts von '>>' angegeben.
Ich nehme an, dass hinter dem & die Bit-Position im Byte steht dass dich interessiert, oder (dataField & 0x0E für bit 1-3)? ` Es ist so das du ein Byte nicht weiter aufteilen kannst, wenn du jetzt ein bestimmtes Bit brauchst musst du alle anderen Bits Nullen. Dafür wird das '& 0x0E' hier verwendet.
Ich finde deine Erklärung für die Daten Telegramme sehr gut.
-
Hallo Jey Cee,
ich habe nun angefangen die Logik für den Aktor zu bauen, aktuell nur mit Testausgabe der Daten:
https://github.com/syryna/ioBroker.enoc … master/eep
bzw.
https://github.com/syryna/ioBroker.enoc ... 5-3f-7f.js
habe ebenfalls die anderen Files angepasst:
EEP2IOB.json
devices.json
eepInclude.js
Das Objekt ist drin und hat ein Empfangssignal:
~~https://snag.gy/Fg2EkJ.jpg" />Auch die Testausgabe im LOG scheint zu gehen, woher die else Zeilen kommen muss ich noch rausfinden.
enocean.0 2019-01-02 00:03:02.126 debug else: status
enocean.0 2019-01-02 00:03:02.125 debug else: data
enocean.0 2019-01-02 00:03:02.125 debug else: type
enocean.0 2019-01-02 00:03:02.125 debug variables to set : {"type":165,"data":{"type":"Buffer","data":[0,6,1,10]},"status":0}
enocean.0 2019-01-02 00:03:02.125 debug Message for ID 0183e523 has been received.
enocean.0 2019-01-02 00:03:02.125 debug Packet type: 1
enocean.0 2019-01-02 00:03:02.114 debug Received raw message: 55000a0701eba50006010a0183e5230003ffffffff4f00
Ich muss nur aufhören die Frau nervt schon weil die Rollos immer hoch und runter fahren, ich mach morgen weiter und versuche die Daten entsprechend in die Felder zu schreiben.
Einen Tipp brauch ich noch: Eigentlich wollte ich die Felder im ioBroker wie folgt konfigurieren:
"FSB61NP": { "devName": "Universal", "iobObjects": [ {"id": "data1","common.name": "runtime MSB","common.type": "number","common.min": "0","common.max": "16777215","common.def": "0", "common.role": "value", "common.states" : "", "common.read": "true", "common.write": "false", "common.unit": "100ms"}, {"id": "data1","common.name": "runtime LSB","common.type": "number","common.min": "0","common.max": "16777215","common.def": "0", "common.role": "value", "common.states" : "", "common.read": "true", "common.write": "false", "common.unit": "100ms"}, {"id": "data1","common.name": "direction","common.type": "number", "common.role": "value", "common.states" : "1:moving up;2:moving down", "common.read": "true", "common.write": "false"}, {"id": "data1","common.name": "locked","common.type": "number", "common.role": "value", "common.states" : "10:not locked;14:locked", "common.read": "true", "common.write": "false"} ]Da die EEP aber universell ist und vermutlich viele Hersteller diese nutzen denke ich aktuell als ein generisches Format:
"native": { "devName": "Universal", "iobObjects": [ {"id": "data1","common.name": "Universal Data 1","common.type": "number","common.min": "0","common.max": "16777215","common.def": "0", "common.role": "value", "common.states" : "", "common.read": "true", "common.write": "false"}, {"id": "data2","common.name": "Universal Data 2","common.type": "number","common.min": "0","common.max": "16777215","common.def": "0", "common.role": "value", "common.states" : "", "common.read": "true", "common.write": "false"}, {"id": "data3","common.name": "Universal Data 3","common.type": "number","common.min": "0","common.max": "16777215","common.def": "0", "common.role": "value", "common.states" : "", "common.read": "true", "common.write": "false"}, {"id": "data4","common.name": "Universal Data 4","common.type": "number","common.min": "0","common.max": "16777215","common.def": "0", "common.role": "value", "common.states" : "", "common.read": "true", "common.write": "false"} ]Was ist deine Meinung dazu ? Generisch ist zwar gut aber dann muss der ioBroker nutzer jedesmal selbst ergründen was in den 4 bytes eigentlich für Daten stehen.
Weiter, ist dir ein Problem bekannt dass nach einer gewissen Zeit einfach keine Messages im LOG erscheinen. Dafür stehen solche Dinge drin:
enocean.0 2019-01-01 23:50:54.798 debug system.adapter.admin.0: logging true
enocean.0 2019-01-01 23:49:34.966 debug system.adapter.admin.0: logging false
Ich konnte noch kein Muster erkennen. Wenn du einen Tips hast wie ich das besser eingrenzen kann, sag bescheid.
Grüße, Michael~~
-
Hallo Jey Cee,
ich hab mich da voll verrannt, Die Ausgabe im Log ist gar nicht von mir sondern von dir aus der main.js
Sprich ich weiß aktuell gar nicht ob meine a5-3f-7f.js aufgerufen wird.
Zu Testzwecken habe will ich Debug Ausgabe einbauen und mir die Werte im Log vom iobroker anzeigen lassen. Aber console.log ergibt keine Ausgabe in den Entwicklertools vom Chrome. Also entweder kann ich console.log hier nicht nehmen oder ich mach was grundlegend falsch. Eventuell komme ich ja nichtmal bis zu meiner JS und daher auch keine Ausgabe.
In der Main.js sehe ich die machst deine Ausgabe so damit sie im ioBroker Log zu finden ist:
adapter.log.debug('variable to set: ' + key);Kann ich das auch so verwenden?
Ich will also erstmal sehen ob ich überhaupt in meinm JS file lande und dann nach und nach die Werte der Bytes und des Typs und Status ausgeben. Soweit komme ich jedoch nicht.
Es könnte auch sein das mein Verweis in der eepInclude.js nicht vernünftig ist, daher wollte ich mal sehen wo der eepInclude.js Verwendung findet, aber konnte das auch bislang nicht finden, hätte vermutet die main.js oder eben die esp3Packet.js wurde darauf verweisen.
Sorry für die vielen Anfängerfragen aber für einen Neuling in einen vorhandenen Adapter einzusteigen ist schwierig. Vielleicht hätte ich erstmal einen kleinen Adapter selbst schreiben sollen um den Aufbau besser zu verstehen.
Grüße, Michael
-
Einen Tipp brauch ich noch: Eigentlich wollte ich die Felder im ioBroker wie folgt konfigurieren: ` Ich bin mir sicher darauf schon geantwortet zu haben, aber der Post ist weg. Deswegen nochmal, bitte bau beide Varianten ein und orientier dich an dem Smokedetector.
Weiter, ist dir ein Problem bekannt dass nach einer gewissen Zeit einfach keine Messages im LOG erscheinen. Dafür stehen solche Dinge drin:
enocean.0 2019-01-01 23:50:54.798 debug system.adapter.admin.0: logging true
enocean.0 2019-01-01 23:49:34.966 debug system.adapter.admin.0: logging false ` Ist mir jetzt noch nicht aufgefallen.
Aber console.log ergibt keine Ausgabe in den Entwicklertools vom Chrome. ` Das wird es nie der Teil vom Code läuft im Backend und du bekommst damit nur in deiner IDE/Editor eine Ausgabe.
https://github.com/ioBroker/ioBroker/wiki/Installation,-setup-and-first-steps-with-an-ioBroker-Development-Environment mal exemplarisch die Einrichtung von Webstorm um zu Debuggen.
Kann ich das auch so verwenden? ` Eher nicht 'adapter' kann nur in der main.js aufgerufen werden.
Es könnte auch sein das mein Verweis in der eepInclude.js nicht vernünftig ist, ` Ja, das ist auch so.
a5_3f_7f_FSB61NP:Muss so aussehen wenn es ein native ist:
a5_3f_7f_native:Das native gibt type wieder welches in devices.json zum Gerät angegeben ist.
Um Speziell den FSB61NP zu verwenden, hier werden dann Speziefisch die Objekte und Funktionen bereit gestellt, ist diene Version richtig. Bitte Orientiere dich an Smokedetector.
Kurz zur Erklärung:
Der Smokedetector verwendet die EEP f6-02-01, stellt aber andere Objekte in ioBroker zur Verfügung, dazu braucht es auch eigene Funktionen. Deshalb gibt es eine eigene js Datei und ein Untertyp für f6-02-01 in EEP2IOB.json.
Das ist notwendig weil die EEP ja in den Telegrammen codiert ist. Anhand der ID wird dann ermittelt wie mit dem Telegramm verfahren wird. Bei der Automatischen Erkennung wird immer der Type native verwendet, Geräte die nicht native sind müssen von Hand angelegt werden.
Sorry für die vielen Anfängerfragen aber für einen Neuling in einen vorhandenen Adapter einzusteigen ist schwierig. ` Hast dir auch den einfachsten dafür ausgesucht
Das passt schon, wenn die Hürden hoch sind ist die Lernkurve meist steiler. -
Hallo liebe Gemeinde,
Bei mir läuft der Adapter rund. Ich wollte nur fragen ob du schon oder noch dabei bist Befehle zu senden.
Also ich habe einen einfachen Aktor mit einem Kanal.
Wenn du mehr Infos brauchst kann ich dir gerne welche geben.
Gesendet von iPhone mit Tapatalk
-
Ich wollte nur fragen ob du schon oder noch dabei bist Befehle zu senden. ` Das hab ich schon noch vor, aber jetzt hab ich mir erstmal einen 2ten USB Stick bestellt. Ist nicht so cool den immer vom Produktiv system ab zu ziehen.
Also ich habe einen einfachen Aktor mit einem Kanal.
Wenn du mehr Infos brauchst kann ich dir gerne welche geben. ` Immer her damit.
-
@Jey Cee:Immer her damit. `
Ich habe den 451 FU-EP von PEHA Easyclick
Auf einem Aufkleber steht „3911 1K1.2“
~~<link_text text="https://uploads.tapatalk-cdn.com/201901 ... b30e05.jpg">https://uploads.tapatalk-cdn.com/20190103/7673c65d9cd52931896ea0f968b30e05.jpg</link_text>" />Gesendet von iPhone mit Tapatalk~~
-
Hallo Jey Cee,
komme mir echt etwas doof vor wenn ich laufend frage. Aber es geht immerhin langsam voran und ich will nicht aufgeben sondern hoffe wenn ich endlich mal Debugausgaben hinbekomme dass ich auch einen Mehrwert zurückgeben kann.
Ich habe mit nun Webstorm installiert auf dem Rechner auf dem auch der USB300 angeschlossen ist, denn nur dort kann ich ja testen. Es macht also keinen Sinn auf meinem Windows Rechner eine Testinstallation von ioBroker zu installieren.
Daher habe ich schon mal das Problem dass meine 'Entwicklungs'-Version vom iobroker.enocean auf meinem Windows PC liegt mit Verbindung zu Git, aber nach jeder kleinen Änderung muss ich das ins Git hochladen damit ich dann auf dem Linux Rechner das Git Archive runterladen und starten kann.
-> Etwas kompliziert, habe aber keine bessere Lösung gefunden. Schöner wäre ich könnte das Git Repo direkt in die ioBroker installation einbinden weiß aber nicht wie das geht.
Aber neben dem umständlichen Entwicklungsumgebung mit der ich noch leben kann komme ich aber mit dem Debugger nicht zu recht und mache alles über die Konsolenausgabe.
Ich habe den Adapter per default im ioBroker deaktiviert, so dass ich ihn manuell im WebStorm starte kann. Ich kann dann in der IDE den Adapter enterweder starten per 'RUN' oder im Debugger starten per 'Debug enocean'.
Wenn ich nur mittels 'run' den modifizierten Adapter starte bekomme ich nun die Konsolen Ausgabe zu Gesicht, ein erster Erfolg :-P:
~~https://snag.gy/mfAJBu.jpg" />Wie du siehst habe ich zwei Konsole Ausgaben und je zwei Dateien.
1.) in deiner Original datei F6-02-01 in header bei den Konstanten:````
console.log("original file");2.) in deiner Original datei F6-02-01 im module.export block:```` console.log("RORG: '" + telegram.type + "'" + " datafield: '" + dataField +"'");3.) in meiner datei A5-3F-7F in header bei den Konstanten:````
console.log("michas file");4.) in meiner datei A5-3F-7F im module.export block:```` console.log("RORG_HEX: '" + RORG + "'" + " RORG: '" + telegram.type + "'");im Bild oben sieht man dass sowohl meine als auch deine datei beim starten durchlaufen wird und die Kommentare "original file" und "michas file" ausgegeben werden.
Wenn ich jetzt einen deiner Taster betätige und damit dein file greift passiert folgendes:
RORG: '246' datafield: '0' RORG: '246' datafield: '112' RORG: '246' datafield: '0'Das heisst ist komme ich einen module.export block und die Ausgabe erfolgt.
Die Log Ausgabe im ioBroker dazu sehen so aus:
enocean.0 2019-01-04 12:00:16.734 debug else: B0 enocean.0 2019-01-04 12:00:16.733 debug else: BI enocean.0 2019-01-04 12:00:16.733 debug else: A0 enocean.0 2019-01-04 12:00:16.733 debug else: AI enocean.0 2019-01-04 12:00:16.733 debug variables to set : {"AI":false,"A0":false,"BI":false,"B0":false} enocean.0 2019-01-04 12:00:16.733 debug Message for ID feff5e0c has been received. enocean.0 2019-01-04 12:00:16.732 debug Packet type: 1 enocean.0 2019-01-04 12:00:16.731 debug Received raw message: 55000707017af600feff5e0c2003ffffffff4f00 enocean.0 2019-01-04 12:00:16.508 debug else: B0 enocean.0 2019-01-04 12:00:16.508 debug variables to set : {"B0":true} enocean.0 2019-01-04 12:00:16.507 debug Message for ID feff5e0c has been received. enocean.0 2019-01-04 12:00:16.507 debug Packet type: 1 enocean.0 2019-01-04 12:00:16.506 debug Received raw message: 55000707017af670feff5e0c3003ffffffff5200 enocean.0 2019-01-04 12:00:04.581 debug else: B0 enocean.0 2019-01-04 12:00:04.581 debug else: BI enocean.0 2019-01-04 12:00:04.581 debug else: A0 enocean.0 2019-01-04 12:00:04.580 debug else: AI enocean.0 2019-01-04 12:00:04.580 debug variables to set : {"AI":false,"A0":false,"BI":false,"B0":false} enocean.0 2019-01-04 12:00:04.580 debug Message for ID feff5e0c has been received. enocean.0 2019-01-04 12:00:04.580 debug Packet type: 1 enocean.0 2019-01-04 12:00:04.579 debug Received raw message: 55000707017af600feff5e0c2003ffffffff4400Jetzt betätige ich meinen Aktor und damit sollte meine Datei und meine Debug Ausgabe erfolgen, aber es passiert folgendes:
1 0 Data length: 1 Optional length:0 1 0 Data length: 1 Optional length:0 RORG: '165' datafield: '0' 1 0 Data length: 1 Optional length:0 1 0 (node:345) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'toString' of undefined at handleType2Message (/opt/iobroker/node_modules/iobroker.enocean/main.js:252:84) at parseMessage (/opt/iobroker/node_modules/iobroker.enocean/main.js:367:13) at esp3parser. <anonymous>(/opt/iobroker/node_modules/iobroker.enocean/main.js:544:13) at emitOne (events.js:116:13) at esp3parser.emit (events.js:211:7) at addChunk (_stream_readable.js:263:12) at readableAddChunk (_stream_readable.js:250:11) at esp3parser.Readable.push (_stream_readable.js:208:10) at esp3parser.Transform.push (_stream_transform.js:147:32) at esp3parser._transform (/opt/iobroker/node_modules/iobroker.enocean/parser/parser.js:35:20) (node:345) UnhandledPromiseRejectionWarning: 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(). (rejection id: 1) (node:345) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.</anonymous>Die Log Ausgabe im ioBroker sieht dazu so aus:
enocean.0 2019-01-04 12:06:37.745 debug Packet type: 2 enocean.0 2019-01-04 12:06:37.744 debug Received raw message: 55000100026500 enocean.0 2019-01-04 12:06:36.542 debug Message for ID 0183e523 has been received. enocean.0 2019-01-04 12:06:36.541 debug Packet type: 1 enocean.0 2019-01-04 12:06:36.540 debug Received raw message: 55000707017af6020183e5233003ffffffff5500 enocean.0 2019-01-04 12:06:36.056 debug Response for command CO_WR_SECUREDEVICE_ADD return code: RET_OK enocean.0 2019-01-04 12:06:36.056 debug Packet type: 2 enocean.0 2019-01-04 12:06:36.055 debug Received raw message: 55000100026500 enocean.0 2019-01-04 12:06:30.286 debug variables to set : {} enocean.0 2019-01-04 12:06:30.285 debug Message for ID 0183e523 has been received. enocean.0 2019-01-04 12:06:30.285 debug Packet type: 1 enocean.0 2019-01-04 12:06:30.284 debug Received raw message: 55000a0701eba50010010a0183e5230003ffffffff5300 enocean.0 2019-01-04 12:06:29.914 debug Response for command undefined return code: RET_OK enocean.0 2019-01-04 12:06:29.914 debug Packet type: 2 enocean.0 2019-01-04 12:06:29.913 debug Received raw message: 55000100026500 enocean.0 2019-01-04 12:06:28.779 debug Message for ID 0183e523 has been received. enocean.0 2019-01-04 12:06:28.779 debug Packet type: 1 enocean.0 2019-01-04 12:06:28.778 debug Received raw message: 55000707017af6010183e5233003ffffffff5200Das eine Signal zum hochfahren und stop kam an daher auch die Ausgabe: RORG: '165' datafield: '0'
Runterfahren und Stop führt aber zu einem Dump. Zeile 245ff in main.js
function handleType2Message(espPacket) { const telegram = new ResponseTelegram(espPacket); let retCode = telegram.data[0]; let resp = telegram.dataLength + ' ' + telegram.optionalLength; console.log(resp); switch(resp){ case '1 0': //Standard Response adapter.log.debug('Response for command ' + returnCommonCMD(lastCMD[0].[color]toString(16)[/color]) + ' return code: ' + returnResponse(retCode.toString(16))); lastCMD.splice(0, 1);Ich glaube es liegt an diesen Responses:
enocean.0 2019-01-04 12:06:29.914 debug Response for command undefined return code: RET_OK
enocean.0 2019-01-04 12:06:29.914 debug Packet type: 2
enocean.0 2019-01-04 12:06:29.913 debug Received raw message: 55000100026500
Warum es in manchen Fällen geht und in manchen nicht verstehe ich ehrlich gesagt nicht. Ich habe mal testweise die HEX-Konvertierung bei mir rausgenommen:
adapter.log.debug('Response for command ' + returnCommonCMD(lastCMD[0]) + ' return code: ' + returnResponse(retCode));Dann scheint es zu gehen:
Data length: 1 Optional length:0 RORG: '165' datafield0: '0' datafield1: '16' datafield2: '2' datafield3: '10' 1 0 Data length: 1 Optional length:0 1 0 Data length: 1 Optional length:0 RORG: '165' datafield0: '0' datafield1: '18' datafield2: '1' datafield3: '10' 1 0 Data length: 1 Optional length:0 1 0 Data length: 1 Optional length:0 RORG: '165' datafield0: '0' datafield1: '20' datafield2: '2' datafield3: '10'-> ich glaube das musst du bei dir ändern, will nicht an deinem Haupt-Coding rumspielen.
Was den Debugger angeht so kann ich breakpoint setzen 'vor' dem module.export Blöcken und bekomme dann auch im Debuffer schöne Ausgabe der Variablen, sobald ich aber innerhalb der module.exports Block einen Breakpoint setze (was ja das interessante wäre da da die Logik drin ist) bekomme ich im Debugger folgende meldung:
(node:1032) [INSPECTOR_ASYNC_STACK_TRACES_NOT_AVAILABLE] Warning: Warning: Async stack traces in debugger are not available on 32bit platforms. The feature is disabled.Ich verstehe nicht warum, wenn du einen Tipp hast wäre ich dankbar ansonsten mache ich weiter mit Konsolenausgaben.
Grüße, Michael~~
-
da fällt mir gerade ein, das könnte doch ein Grund sein für meine Nachrichten die scheinbar nicht ankommen.
Wäre es möglich dass durch eine solche Nachricht mit dem 'undefined' Wert der Adapter abstürtzt und neu gestartet wird durch ioBroker? Wenn dem so wäre dann ist das genau der Zeitraum zwischen der Exception und dem hochfahren des Adapters wo natürlich keine Nachrichten mitgeloggt werden können.
Grüße, Michael
-
Hi Jey Cee,
die neue EEP mit der Variante for den FSB61NP sind fertig. Ich habe einen pull-request gestellt. Ich habe nun doch mal in der main.js Zeile 252 das entfernt:
.toString(16)vom lastCMD.
So sieht das Ergebnis aus:
~~https://snag.gy/tEb07u.jpg" />Umd so die Werte:
~~https://snag.gy/Gx6s90.jpg" />Und so das log:
~~https://snag.gy/Mbavc2.jpg" />ABER, ganz wichtig da musst du nochmal schauen.
Die 'A5' Messages sind ja BS4 und da greift meine Logik, sie werden verwendet um die Aktion des Aktors zurückzugeben (Responses):
-
Laufzeit MSB ->>>> Y x 100ms
-
Laufzeit LSB ->>>> Z x 100ms
-
letzte Aktion: 1/2 für nach oben und nach unten
-
lock: 10/14 für nicht blockiert / blockiert
Die 'F6' Messages sind ja RPS und zeigen dem Status des Aktors an, zum Beispiel wenn er den Befehl bekommen hat nach oben oder unten zu fahren:
- Status: fahre hoch / fahre runter / Endposition Oben erreicht / Endposition unten erreicht.
Leider sind die 'lila' markierten Bereiche in den Screenshots nicht funktionafähig. Das betrifft genau diese Type 1 Messages (RPS / F6). Scheinbar werden da unserer xx-xx-xx.js Files nicht gerufen.
Kannst du mal nachsehen? Ich kann das nach einem Fix natürlich testen.
Habe die Logik dafür eigentlich drin:
case 'f6': // RPS Message - command to Actor retValue = { "status": DataPayLoad["byte0"] }; break;Der Aufbau ist wie folgt:
enocean.0 2019-01-04 17:22:49.052 debug Message for ID 0183e523 has been received.
enocean.0 2019-01-04 17:22:49.052 debug Packet type: 1
enocean.0 2019-01-04 17:22:49.051 debug Received raw message: 55000707017af6700183e5233003ffffffff5500
enocean.0 2019-01-04 17:21:48.760 debug Message for ID 0183e523 has been received.
enocean.0 2019-01-04 17:21:48.760 debug Packet type: 1
enocean.0 2019-01-04 17:21:48.759 debug Received raw message: 55000707017af6010183e5233003ffffffff5200
Von unten:
1.) es kommt eine message die besagt 'hochfahren' (01): 55000707017af6010183e5233003ffffffff5200
2.) nach einer im Aktor eingestellten Zeit (bei mir 1 min) schick tder Aktor eine Nachricht 'endposition oben erreicht' (70): 55000707017af6700183e5233003ffffffff5500
-> die will ich noch auswerten können, verstehe aber nicht warum das nicht bei mir ankommt im Script. Es ist do wie die anderen Messages eine Type 1?
Grüße, Michael~~~~~~
-
-
Hallo,
ich teste gerade mit einem Eltako FTKE. Es wird wie bei Syryna nur die Signalsärke erkannt aber nicht der eigentliche Schaltzustand. Der Workaround über PTM 200 hat auch nicht funktioniert. ID wird korrekt erkannt. EEP habe ich auch mal manuell eingestellt ohne erfolg.
Received raw message: 55000707017af6f0fefaf4682001ffffffff5c00 = geschlossen
Received raw message: 55000707017af6e0fefaf4682001ffffffff5c00 = offen
In der Raw message kann man sehen das der Wert für f0 für geschlossen steht und e0 für offen.
Wie bekomm ich es hin, das an einen Datenpunkt zu knüpfen?
Viele Grüße
