Test Adapter EnOcean v0.3.x
-
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
-
Ich habe mir diese kleine Schönheit hier bestellt und heute erhalten: https://www.amazon.de/gp/product/B01DRO7B2U/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1
Freue mich schon darauf, den Adapter bald zu testen, wenn noch ein paar enOcean-Komponenten und die Antenne hier eintreffen!
-
Hallo zusammen,
habt ihr schon erfolgreich Eltako/Enocean-Geräte bei IoBroker installieren und steuern können?
-
Hi zusammen,
nach einem SD Karten defekt, habe ich das System neu aufgesetzt. Hat mit meinem Backup super funktioniert.
Allerdings findet das System den USB300 Stick nicht mehr, der Punkt "Schnittstelle" bleibt leer.
per SSH gibt #lsusb den Stick am richtigen Port wieder.
Woran kann es liegen?
Tinker Board
ioBroker Image für Tinkerboard (S) 20190813
node v10.16.3
npm 6.9.0keine Fehler im Log
-
@AxelF1977 der Adapter muss laufen damit er die Ports finden kann.
-
@Jey-Cee, danke für die schnelle Antwort.
Adapter läuft, er hat auch noch die alten angelernten Taster drinn durch das Backup. Nur die Ports findet er nicht. Vor dem Absturz ging es perfekt
Habe den Adapter schon mehrmals neu gestartet.
Die Instanz zu löschen und neu zu installieren hab ich allerdings noch nicht, wollte nicht alles neu anlernen.
-
@AxelF1977 du kannst die Objektstruktur exportieren und später wieder importieren, sie enthält alles nötige. Das erspart das neu anlernen.
In der Objektübersicht oben bei den Buttons geht das.
-
@Jey-Cee also, der Export gab zwar eine Datei, die war aber wohl leer. Sei es drum. Den Adapter komplett deinstalliert, neu installiert und die Instanz neu angelegt haben den Erfolg gebracht.
Ich konnte die Taster gleich wieder per Autodetect neu anlernen. Zum Glück sind die Taster nicht aus den Javascripten geflogen, so das diese gleich wieder laufen. Das war die Befürchtung die ich hatte.Vielen Dank für Deine schnelle Hilfe!
-
Hallo,
Erstmal vielen Dank für den Adapter.
Aktuell bin ich in gerade in Verbindung mit den neueren Hoppe SecuSignal Fenstergriffen am testen.Währen die Open Information eigentlich immer Sauber einläuft registriert er bei geschlossen gekippt.
Bei gekippt jedoch überhaupt keine Information.Falls du noch weitere infos brauchst stehe ich dir zur Verfügung.
-
@9_Mad-Max_5 Stelle die Log Stufe für enOcean in der Instanz Übersicht mal auf Debug. Dafür musst du den Expertenmodus, links oben, Aktivieren.
Dann gibt das Log deutlich mehr Informationen Preis ob überhaupt eine Nachricht angekommen ist. -
Mhm shit bin gerade selber nicht zu hause um es zu testen.
So drum habe ich es einmal bedienen lassen.2019-11-18 20:03:53.840 - debug: enocean.0 (4152) Received raw message: 55000707017af6d0019b0ffa2000ffffffff5c00 2019-11-18 20:03:53.841 - debug: enocean.0 (4152) Packet type: 1 2019-11-18 20:03:53.846 - debug: enocean.0 (4152) Message for ID 019b0ffa has been received. 2019-11-18 20:03:53.848 - debug: enocean.0 (4152) variables to set : {"window_handle":2} 2019-11-18 20:03:53.849 - debug: enocean.0 (4152) else: window_handle 2019-11-18 20:03:54.286 - debug: enocean.0 (4152) Received raw message: 55000707017af6e0019b0ffa2000ffffffff5b00 2019-11-18 20:03:54.288 - debug: enocean.0 (4152) Packet type: 1 2019-11-18 20:03:54.289 - debug: enocean.0 (4152) Message for ID 019b0ffa has been received. 2019-11-18 20:03:54.291 - debug: enocean.0 (4152) variables to set : {"window_handle":1} 2019-11-18 20:03:54.293 - debug: enocean.0 (4152) else: window_handle 2019-11-18 20:03:56.890 - debug: enocean.0 (4152) Received raw message: 55000707017af6f0019b0ffa2000ffffffff5f00 2019-11-18 20:03:56.891 - debug: enocean.0 (4152) Packet type: 1 2019-11-18 20:03:56.891 - debug: enocean.0 (4152) Message for ID 019b0ffa has been received. 2019-11-18 20:03:56.892 - debug: enocean.0 (4152) variables to set : {"window_handle":0} 2019-11-18 20:03:56.893 - debug: enocean.0 (4152) else: window_handleDa ist der Output der auch gut aussieht.
Diesmal hat er auch closed eingelesen.
Habe ich den griff vielleicht zu schnell oder zu langsam geöffnet gibt es da was bei den Paketen zu beachten? -
@Jey-Cee :
Nun habe ich es nochmal bedient.
Das ist ein komplettes öffnen auf kipp und schließen des Fensters.
Der letzte state ist wie man sehen kann gekippt.
Auch wenn nun das Fenster wieder geschlossen ist.enocean.0 2019-11-22 15:15:02.021 debug (4152) else: window_handle enocean.0 2019-11-22 15:15:02.019 debug (4152) variables to set : {"window_handle":2} enocean.0 2019-11-22 15:15:02.014 debug (4152) Message for ID 019b0ffa has been received. enocean.0 2019-11-22 15:15:02.012 debug (4152) Packet type: 1 enocean.0 2019-11-22 15:15:02.011 debug (4152) Received raw message: 55000707017af6d0019b0ffa2000ffffffff5c00 enocean.0 2019-11-22 15:15:01.549 debug (4152) else: window_handle enocean.0 2019-11-22 15:15:01.548 debug (4152) variables to set : {"window_handle":1} enocean.0 2019-11-22 15:15:01.548 debug (4152) Message for ID 019b0ffa has been received. enocean.0 2019-11-22 15:15:01.547 debug (4152) Packet type: 1 enocean.0 2019-11-22 15:15:01.546 debug (4152) Received raw message: 55000707017af6c0019b0ffa2000ffffffff5900 enocean.0 2019-11-22 15:14:52.379 debug (4152) else: window_handle enocean.0 2019-11-22 15:14:52.378 debug (4152) variables to set : {"window_handle":2} enocean.0 2019-11-22 15:14:52.377 debug (4152) Message for ID 019b0ffa has been received. enocean.0 2019-11-22 15:14:52.376 debug (4152) Packet type: 1 enocean.0 2019-11-22 15:14:52.374 debug (4152) Received raw message: 55000707017af6d0019b0ffa2000ffffffff5b00 enocean.0 2019-11-22 15:14:52.188 debug (4152) else: window_handle enocean.0 2019-11-22 15:14:52.187 debug (4152) variables to set : {"window_handle":1} enocean.0 2019-11-22 15:14:52.185 debug (4152) Message for ID 019b0ffa has been received. enocean.0 2019-11-22 15:14:52.184 debug (4152) Packet type: 1 enocean.0 2019-11-22 15:14:52.183 debug (4152) Received raw message: 55000707017af6e0019b0ffa2000ffffffff5c00 enocean.0 2019-11-22 15:14:52.044 debug (4152) else: window_handle enocean.0 2019-11-22 15:14:52.043 debug (4152) variables to set : {"window_handle":2} enocean.0 2019-11-22 15:14:52.041 debug (4152) Message for ID 019b0ffa has been received. enocean.0 2019-11-22 15:14:52.041 debug (4152) Packet type: 1 enocean.0 2019-11-22 15:14:52.039 debug (4152) Received raw message: 55000707017af6d0019b0ffa2000ffffffff5b00 -
@9_Mad-Max_5 soweit ich das beurteilen kann ist der State entsprechend den Datentelegrammen OK. Ich hab keinen dieser Griffe und hab auch die Integration dafür nicht gemacht, aber wenn ich das richtig verstehe ist da ein Vibrationssensor drin und der scheint recht empfindlich zu sein. Deshalb springt der immer auf tilt (geöffnet).
Da ist Software seitig nichts zu machen, vielleicht kann man die Empfindlichkeit am Griff einstellen. -
@Jey-Cee
Soweit ich das weis wird durch die bewegung des Griffs ein elektrischer impuls ausgesendet.
Hierbei geht der griff recht schwer und man bewegt ihn in der idee gegen einen Dynamo.
Dieser kennt den Ausgangspunkt und bei einer Drehung um etwa 90° sendet er open.Weist du wer diese Integration gemacht hat?
Bzw wie komme ich weiter mit der nicht guten erkennung? -
benutzt du node-enocean?
Hast du gesehen das es mittlerweile was neues von ihm gibt?
Es heißt enocean-js. Leider verstehe ich nicht genau was es ist um ehrlich zu sein.Könnte man das anstatt als basis für den enocean Adapter benutzen?
-
@9_Mad-Max_5 ja das war @Darnat, der ist aber wohl schon lange nicht mehr hier gewesen.
Wie gesagt das Problem liegt am/im Griff der sendet ein Datentelegramm und das wird interpretiert. Wenn man am Griff nichts einstellen kann ist da nix zu machen.
Da hilft auch keine andere Basis.
Aber der EnOcean Adapter nutzt seine eigene Basis an, die haben Darnat, AlCalzone und ich geschrieben. -
@Jey-Cee ah ok ihr habt das alle zusammen gemacht.
Gibt es eine möglichkeit die rohdaten anzusehen?
Also das was der enocean 300 Stick selbst empfängt?Der Adapter interpretiert doch sicherlich die Telegramme die eingehen oder?
