Adapter stops with error

[tomschlde]

Once or twice a day the adpter stops with the mesage in the log:

` gruenbeck.0	2020-03-12 08:18:16.554	error	(1690) SyntaxError: Unexpected token { in JSON at position 10
gruenbeck.0	2020-03-12 08:18:16.536	error	(1690) Websocket parse error`

No more data is written to the influx-adapter.

Restart helps.

[TA2k]

Ich habe mal versucht ein reconnect hinzuzufügen. Bitte installiere via github und starte die grünbeck instanze neu. Behalte den Adapter im Augen was dann für Fehler kommen.

[tomschlde]

THX. Habs installiert - ich prüfe das und melde mich.

[tomschlde]

Scheint zu funktionieren:

`

gruenbeck.0	2020-03-13 04:42:27.557	info	(26454) Websocket closed
gruenbeck.0	2020-03-13 04:42:27.556	info	(26454) 1000
gruenbeck.0	2020-03-13 04:42:27.523	error	(26454) {"type":6}{"type":1,"target":"SendMessageToDevice","arguments":[{"id":"BS400XXXXX","type":"Current","ibuiltindev":true,"isncu":"201910181088","mregpercent1":100,"mregpercent2":0,"mremregstep
gruenbeck.0	2020-03-13 04:42:27.522	error	(26454) SyntaxError: Unexpected token { in JSON at position 10
gruenbeck.0	2020-03-13 04:42:27.507	error	(26454) Websocket parse error

`

und die Aufzeichnung geht weiter.

Danke.

[tomschlde]

Schade, mittlerweile steigt der Adapter ohne Fehlermeldung aus und influxdb bekommt keinen Daten mehr. Andere Anwendungen schreiben weiterhin Daten in die DB. Neustart behebt das Problem. Kann man evtl. mehr loggen?

[TA2k]

Auch im debug gibt er keine Infos aus?

[tomschlde]

Wo kann man das einstellen? Hatte schon gesucht, aber kein loglevel gefunden...

Das dropdown im Log steht auf debug - es kommt von gruenbeck aber nichts, was den stop erklärt...

[TA2k]

Instanzen. Experten Modus einschalten. Dann wird die Spalte log Level sichtbar.

[tomschlde]

Ok ich lass das mal so laufen, bis die Daten stoppen. THX

[tomschlde]

OK, das letzte Lebenszeichen war heute morgen:

info.0	2020-03-24 09:36:07.454	info	(22695) Popup news was read...
gruenbeck.0	2020-03-24 09:15:10.519	debug	(30133) system.adapter.admin.0: logging false
gruenbeck.0	2020-03-24 09:15:00.513	debug	(30133) system.adapter.admin.0: logging true
gruenbeck.0	2020-03-24 09:14:48.528	debug	(30133) {"type":6}
gruenbeck.0	2020-03-24 09:14:43.528	debug	(30133) {"type":6}
gruenbeck.0	2020-03-24 09:14:37.530	debug	(30133) {"type":6}

[dsgrafiniert]

Seid ihr hier schon weiter? Ich portiere die Implementierung gerade auf OpenHAB und habe das selbe Problem. Ich bekomme vom Websocket nur type:6 zurück, jedoch keine Daten.

[RonnyWinkler]

Hallo, ich habe zu dem Problem nach dem SignalR-Code type:6 folgendes gefunden:

https://docs.beaxy.com/docs/connection

type:6 ist eine keep-alive-Nachricht, die mit dieser Nachricht beantwortet werden muss (soweit ich das verstanden habe), { "type": 2, "invocationid": 0, "item": { ... }
}

Vielleicht hilft das bei der Suche nach einer Lösung.

[RonnyWinkler]

Noch ein paar Details zu den SignalR-Nachrichten. Wenn diese Doku und Beispiele den für Grünbeck verwendeten Service betreffen, dann könnten die Beispiele evtl. zur Lösung führen.

https://github.com/aspnet/SignalR/blob/master/specs/HubProtocol.md

=> Ping Message Encoding A Ping message is a JSON object with the following properties: type - A Number with the literal value 6, indicating that this message is a Ping. Example { "type": 6 }

=> Nachrichtenfolge: Streamed Result (Stream example above) C->S: StreamInvocation { Id = 42, Target = "Stream", Arguments = [ 5 ] } S->C: StreamItem { Id = 42, Item = 0 } S->C: StreamItem { Id = 42, Item = 1 } S->C: StreamItem { Id = 42, Item = 2 } S->C: StreamItem { Id = 42, Item = 3 } S->C: StreamItem { Id = 42, Item = 4 } S->C: Completion { Id = 42 }

Client muss vermutlich den typ:6-Ping mit StreamInvocation (type:4) beantworten: { "type": 4, "invocationId": "123", "target": "Send", "arguments": [ 42, "Test Message" ] }

Der Server schickt dann hoffentlich die Anzahl der angeforderten Stream-Pakete (im Beispiel 5).

Ich bin mit dem JavaScript-Coding bzw. den in JS verfügbaren Websocket-Methoden nicht vertraut. Die Prüfung auf die Antwort type:6 muss vermutlich hier ergänzt werden: main.js Zeile 435: ws.on("message", (data) => { bzw. eine Prüfung auf den Nachrichteninhalt in Zeile 439: if (message.arguments) { Hier muss vermutlich zwischen dem Ping (type:6) und der eigentlichen Nachricht (type:2?) unterschieden werden, Bei type:6 muss die StreamInvocation-Nachrichte gesendet werden.

Ich hoffe, ich habe die Doku bis hier richtig verstanden. Ich würde das auch gern testen, bräuchte dazu aber etwas Hilfe bei JS-Coding zum Prüfen/Senden der Nachrichten.

[TA2k]

fixed

[RonnyWinkler]

Hallo TA2k,

Ich habe die neueste github-Version in ioBroker installiert. Es kommt aber immer noch die type:6-Info im Log und keine Daten vom Gerät. Ist bei der neuen Version etwas zu beachten?

Anbei das Log:

gruenbeck.0	2020-12-01 16:37:16.748	debug	(4732) {"type":6}
gruenbeck.0	2020-12-01 16:37:11.746	debug	(4732) {"type":6}
gruenbeck.0	2020-12-01 16:37:06.747	debug	(4732) {"type":6}
gruenbeck.0	2020-12-01 16:37:01.745	debug	(4732) {"type":6}
gruenbeck.0	2020-12-01 16:36:55.744	debug	(4732) {"type":6}
gruenbeck.0	2020-12-01 16:36:55.084	debug	(4732) {}
gruenbeck.0	2020-12-01 16:36:55.015	debug	(4732) WS connected
gruenbeck.0	2020-12-01 16:36:52.602	info	(4732) starting. Version 0.0.20 in /opt/iobroker/node_modules/iobroker.gruenbeck, node: v12.19.0, js-controller: 3.1.5

[TA2k]

Funktioniert der Adapter wenn du nicht die App öffnest

[RonnyWinkler]

Zuerst einmal vielen Dank für deine Arbeit und die Fehlersuche!

Leider liefert der Adapter mit Version 0.20 das gleiche Ergebnis wie 0.18. Die Stream-Daten werden nicht abgerufen. Es kommen wie zuvor nur die type:6-Log-Einträge. Die Stream-Daten (also WebSocket) kommen erst in ioBroker an, wenn die Grünbeck-App parallel geöffnet ist (und auch nur so lange, wie die App aktiv ist). Sobald die App geschlossen ist oder zurück zur Geräteseite gewechselt wird, bricht die Übertragung in ioBroker ab. Das ist beliebig wiederholbar.

Außerdem ist mit 0.20 noch eine Änderung aufgefallen: Bis 0.18 werden die Daten in ioBroker unter gruenbeck. / BSxxxxx / gespeichert. Ab 0.20 werden die Daten unter gruenbeck.0 / softliQ / D/BSxxxxx / gespeichert? Ist das so gewollt? Ist ggf. eine Info in der Versionsdoku wert, weil man ggf. wie bei mir die MQTT-Pusblish-Einstellungen auf die neuen Elemente übertragen muss.

PS: Hast du Kontakt zu Grünbeck? Für micht sieht es so aus, als ob die Verbindung vom Client aktiv getriggert werden muss, danmit der Server die Gerätedaten streamt. Kann es sein, dass man das mit den SignalR-StreamInvocation-Nachrichten anstoßen muss? Ich finde es prinzipiell unglücklich, dass Grünbeck WS verwendet. Wir brauchen in ioBroker ja keinen Live-Stream. Die aktuellen Verbrauchsdaten (also Rest-Wasser) als JSON würde ja genügen.

[TA2k]

Adapter funktioniert solange nicht die App geöffnet ist oder geöffnet wird ich schaue mir das aber nochmal im detail an

[RonnyWinkler]

Hi, der Adapter selbst funktioniert. Es werden nur keine Live-Daten abgerufen (Strean/WebSocket üder SignalR). Die Daten kommen erst beim Adapter als Websocket-Nachricht an, wenn parallel der Abruf über die App erfolgt.

Hast du eine SD-Anlage zum Test? Ich habe zur Veranschaulichung ein Video des Verhaltens gemacht. Ist aber ~80MB als mp4. Ich kann das so nicht hochladen. Kann ich dir das schicken (PN oder Mail)? Hier schon ein paar Screenshots. Ich habe wieder 0.18 verwendet. Das Verhalten bei 0.20 ist aber identisch.

1) Start des Adapters. Keine Daten von SignalR, nur die type:6 ping-Nachrichten:

2) Aktivierung des Abrufs über die App. SignalR-Daten kommen beim Adapter an:

3) Beenden des Abrufs in der App: Keine Daten mehr von SignalR im Adapter, nur noch die type:6-Ping-Nachrichten:

Melde dich bitte bei Fragen. Ich kann eine Beta-Version auch zum Test über github installieren und die eine Rückmeldung geben. Viel Erfolg ;-)

[TA2k]

Ich habe in der Github version nochmal ein Anpassung gemacht müsste jetzt alle 6min auch mit geöffneter App gehen

[RonnyWinkler]

Bin mir nicht sicher, ob wir uns richtig verstanden haben... Aktuelles Verhalten bei den WebSocket-Daten ist: -die Daten werden in Normalfall NIE übertragen -einzige Ausnahme: Die App ist geöffnet UND in der App ist der Live-Abruf aktiv

Ziel für den Adapter sollte ja sein, die Websocket-Daten immer abzurufen. Aktuell MUSS man parallen immer die Daten in der App abrufen, damit der Adapter ebenfalls die Daten empfängt.

[TA2k]

Bitte v.0.0.21 testen

[RonnyWinkler]

Hi, eben mit 0.0.21 getestet: Gleiches Verhalten wie zuvor. Keine Live-Daten vom SD-Gerät (WebSocket/SignalR, z.B. keine Restwassermenge Stream.mrescapa1) Alles nur mit ioBroker-Adapter getestet, ohne Grünbeck-App.

[TA2k]

Restkapazität kommt nicht zurück aber Sachen wie: mcountreg":195,"mcountwater1":90514,"mcountwater2"

[RonnyWinkler]

Ah, da haben wir aneinander vorbei geredet :-) Stimmt, die Statistikdaten kommen. Aber der eigentlich interessante Wert für ein Dashboard ist die Restkapazität. Und die kommt leider nur in den Live-Daten. Und die erhält der Adapter nur, wenn man parallel die App startet. Nur dann erhält das SD-Gerät (oder SignalR-Server) die Aufforderung Live-Daten zu senden. Bis zum Sommer hat das SD-Gerät diese Daten auch an den Adapter gesendet. Seit dem Update seitens Grünbeck funktioniert das nicht mehr. Das Problem haben auch andere Entwickler (dsgrafiniert weiter oben in diesem Issue).

Zum Hintergrund: Ich verwende die Adapterdaten per MQTT in einem HomeAssistant-Dashboard: Daher meine Frage nach den Live-Daten.

Hast du technische Details zu der Schnittstelle von Grünbeck? Könntest du prüfen, was hier noch an der WebSocket-Kommunikation fehlt? Ich würde gern helfen - und wenn nur mit Test. Es wäre schön, wenn es dazu noch eine Lösung geben könne. Falls nicht, dann trotzdem Danke für dein Engagement.

[TA2k]

Ich habe mal eine 0.0.22 erstellt schau mal ob sie mehr Daten ausgibt.

[RonnyWinkler]

Wow, bist du schnell! Das sieht sehr gut aus :-)

Jetzt kommen die Live-Daten (SendMessageToDevice).

In den Objektdaten wird die Kapazität auch aktualisiert. Die Daten stehen nun zwar statt unter gruenbeck.0/BSxxxxx/Stream nun unter gruenbeck.0/softliQ/D/BSxxxxx/Stream. Aber das ist schon ok. Ich muss nur den neuen Elementen die MQTT-Topics wieder zuordnen. Eine Frage aus Neugier: was hast du dafür im Code geändert?

[RonnyWinkler]

Hallo,

ich hatte das Update auf 0.0.23 getestet. Die Version liefert keine erweiterten SD-Daten mehr (mrescapa1). Ein Downgrade auf 0.0.22 funktioniert auch nicht mehr (siehe Log). Version 0.0.22 würde mir ertmal genügen. Danke fürs Prüfen.

0 info it worked if it ends with ok 1 verbose cli [ 1 verbose cli '/usr/bin/node', 1 verbose cli '/usr/bin/npm', 1 verbose cli 'install', 1 verbose cli 'iobroker.gruenbeck@0.0.22', 1 verbose cli '--loglevel', 1 verbose cli 'error', 1 verbose cli '--prefix', 1 verbose cli '/opt/iobroker' 1 verbose cli ] 2 info using npm@6.14.8 3 info using node@v12.19.0 4 verbose config Skipping project config: /opt/iobroker/.npmrc. (matches userconfig) 5 verbose npm-session 5f56583432c4b36d 6 silly install loadCurrentTree 7 silly install readLocalPackageData 8 http fetch GET 200 https://registry.npmjs.org/iobroker.gruenbeck 72ms (from cache) 9 silly registry:manifest no matching version for iobroker.gruenbeck@0.0.22 in the cache. Forcing revalidation. 10 http fetch GET 200 https://registry.npmjs.org/iobroker.gruenbeck 408ms 11 silly fetchPackageMetaData error for iobroker.gruenbeck@0.0.22 No matching version found for iobroker.gruenbeck@0.0.22. 12 timing stage:rollbackFailedOptional Completed in 3ms 13 timing stage:runTopLevelLifecycles Completed in 4022ms 14 verbose type version 15 verbose stack iobroker.gruenbeck: No matching version found for iobroker.gruenbeck@0.0.22. 15 verbose stack at pickManifest (/usr/lib/node_modules/npm/node_modules/npm-pick-manifest/index.js:122:13) 15 verbose stack at /usr/lib/node_modules/npm/node_modules/pacote/lib/fetchers/registry/manifest.js:43:18 15 verbose stack at tryCatcher (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) 15 verbose stack at Promise._settlePromiseFromHandler (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:517:31) 15 verbose stack at Promise._settlePromise (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:574:18) 15 verbose stack at Promise._settlePromise0 (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:619:10) 15 verbose stack at Promise._settlePromises (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:699:18) 15 verbose stack at _drainQueueStep (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:138:12) 15 verbose stack at _drainQueue (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:131:9) 15 verbose stack at Async._drainQueues (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:147:5) 15 verbose stack at Immediate.Async.drainQueues [as _onImmediate] (/usr/lib/node_modules/npm/node_modules/bluebird/js/release/async.js:17:14) 15 verbose stack at processImmediate (internal/timers.js:461:21) 16 verbose cwd /opt/iobroker 17 verbose Linux 4.14.24-qnap 18 verbose argv "/usr/bin/node" "/usr/bin/npm" "install" "iobroker.gruenbeck@0.0.22" "--loglevel" "error" "--prefix" "/opt/iobroker" 19 verbose node v12.19.0 20 verbose npm v6.14.8 21 error code ETARGET 22 error notarget No matching version found for iobroker.gruenbeck@0.0.22. 23 error notarget In most cases you or one of your dependencies are requesting 23 error notarget a package version that doesn't exist. 24 verbose exit [ 1, true ]

[TA2k]

Danke für den Hinweis bei der 23 sind leider Änderung verloren gegangen jetzt ist bei 0.0.24 wieder alles drin

[RonnyWinkler]

Top Arbeit! Vielen Dank. Ich würde dir gern ein kleines Dankeschön zukommen lassen - virtuelles Bierchen, Kaffee, was auch immer :-) Hast du einen Paypal-Link?

[lxnoid]

Ah, da haben wir aneinander vorbei geredet :-) Stimmt, die Statistikdaten kommen. Aber der eigentlich interessante Wert für ein Dashboard ist die Restkapazität. Und die kommt leider nur in den Live-Daten. Und die erhält der Adapter nur, wenn man parallel die App startet. Nur dann erhält das SD-Gerät (oder SignalR-Server) die Aufforderung Live-Daten zu senden. Bis zum Sommer hat das SD-Gerät diese Daten auch an den Adapter gesendet. Seit dem Update seitens Grünbeck funktioniert das nicht mehr. Das Problem haben auch andere Entwickler (dsgrafiniert weiter oben in diesem Issue).

Zum Hintergrund: Ich verwende die Adapterdaten per MQTT in einem HomeAssistant-Dashboard: Daher meine Frage nach den Live-Daten.

Hast du technische Details zu der Schnittstelle von Grünbeck? Könntest du prüfen, was hier noch an der WebSocket-Kommunikation fehlt? Ich würde gern helfen - und wenn nur mit Test. Es wäre schön, wenn es dazu noch eine Lösung geben könne. Falls nicht, dann trotzdem Danke für dein Engagement.

Das ist vielleicht etwas offtopic, aber wie realisierst du die Anbindung an home assistant per MQTT? Hast du eine iobroker Instanz und syncs auf HA?

[RonnyWinkler]

Das ist vielleicht etwas offtopic, aber wie realisierst du die Anbindung an home assistant per MQTT? Hast du eine iobroker Instanz und syncs auf HA?

Ich habe ioBroker als COntainer, dort den Gruenbeck-Adapter installiert. Die Objektdaten werden durch die Topic-Angabe je Element per MQTT exportiert. In HomeAssistant sind MQTT-Sensoren zu diesen Topics angelegt, mit denen die SD-Daten von MQTT in HA importiert werden. Dabei kann gleich noch die Daten umrechnen (m³=>Liter) oder das Rest-Salz berechnen. Also: ioBroker => MQTT-Broker => HA

[lxnoid]

Danke, habe ich inzwischen seit heute morgen auch schon am Laufen. Bis auf das Umrechnen. Habe ja genug Daten.

Iobroker war am Anfang ein wenig seltsam, aber nicht so wie fhem

---

Mit freundlichen Grüßen, Alex Nagel

rywr notifications@github.com schrieb am Do., 21. Jan. 2021, 22:05:

Das ist vielleicht etwas offtopic, aber wie realisierst du die Anbindung an home assistant per MQTT? Hast du eine iobroker Instanz und syncs auf HA?

Ich habe ioBroker als COntainer, dort den Gruenbeck-Adapter installiert. Die Objektdaten werden durch die Topic-Angabe je Element per MQTT exportiert. In HomeAssistant sind MQTT-Sensoren zu diesen Topics angelegt, mit denen die SD-Daten von MQTT in HA importiert werden. Dabei kann gleich noch die Daten umrechnen (m³=>Liter) oder das Rest-Salz berechnen. Also: ioBroker => MQTT-Broker => HA

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/TA2k/ioBroker.gruenbeck/issues/12#issuecomment-764941180, or unsubscribe https://github.com/notifications/unsubscribe-auth/APFELBH2WDQVUJYXI4F7FZTS3CJJXANCNFSM4LGKYDGQ .