@dieter_p Habe einen Shelly 1PM Gen4 bei mir im Einsatz seit heute mit IOBroker:

Der Shelly Adapter meldet (über dessen interne Abbildung des MQTT Protokolls), dass er das Gen4 Gerät noch nicht kennt (WLAN).

Mit dem Standard MQTT Broker/Client lässt sich jedoch mit dem Gerät kommunizieren (WLAN), allerdings musste ich die Telegramme/Datenpunkte erst per Script parsen.

Mit Zigbee (deshalb hatte ich mir das Gerät eigentlich gekauft) habe ich etwas experimentiert, aber über ein "Announce" des Geräts im Pairing-Fenster von IOBroker bin ich nicht hinausgekommen: Das Interview wurde nicht abgeschlossen.

Es wird wohl so sein, wie Asgothian schreibt: Das Gerät muss in die zigbee-herdsman-converters aufgenommen werden.

Falls es jemanden hilft: Bei mir seit gestern Abend auch entsperrt, ohne konkrete Email als Info zur Entsperrung dazu. Zuvor aber alle paar Tage mit dem Support telefoniert und Mails ausgetauscht.

Auffällig war bei mir ebenso, dass eine IP-Sperre aktiv (Vodafone, kein IP-Wechsel bei Reconnect der Fritzbox) war, da im Mobilfunknetz zumindest id.worx.com einsehbar war (sonst aber weder App noch account.worx.... funktionierte)

IOBroker-Adapter nutze ich (derzeit) nicht mehr.

@dieter_p Habe einen Shelly 1PM Gen4 bei mir im Einsatz seit heute mit IOBroker:

Der Shelly Adapter meldet (über dessen interne Abbildung des MQTT Protokolls), dass er das Gen4 Gerät noch nicht kennt (WLAN).

Mit dem Standard MQTT Broker/Client lässt sich jedoch mit dem Gerät kommunizieren (WLAN), allerdings musste ich die Telegramme/Datenpunkte erst per Script parsen.

Mit Zigbee (deshalb hatte ich mir das Gerät eigentlich gekauft) habe ich etwas experimentiert, aber über ein "Announce" des Geräts im Pairing-Fenster von IOBroker bin ich nicht hinausgekommen: Das Interview wurde nicht abgeschlossen.

Es wird wohl so sein, wie Asgothian schreibt: Das Gerät muss in die zigbee-herdsman-converters aufgenommen werden.

@mcu Danke dafür, aber bei "err" handelt es sich bei mir lediglich um einen Datentyp String. Vielleicht hast Du noch eine ältere Codebasis (?) des JS-Controllers? Bin bei Version 7.0.6. Der Code funktioniert also in der Form bei mir so nicht. Ich vermute aber, dass das keinen Unterschied machen wird.

Hintergrund:

Der störende Logeintrag wird meines Verständnisses nach VOR dem Ausführen der Callback-Funktion (alles innerhalb der geschweiften Klammern ab "=>" { ... Callbackfunktion ... }" erzeugt. Dein Vorschlag zielt darauf ab, innerhalb der Callback-Funktion das Fehlerhandling noch etwas detaillierter durchzuführen, aber da ist der Logeintrag leider bereits erzeugt worden...

Ok danke Euch, dann nutze ich den Lichtsensor weiter um die Abfragen nur dann durchzuführen, wenn der Lichteinfall den Wechselrichter versorgt und er erreichbar ist.

@oliverio Danke, der Weg mit dem Issue und der Option wäre vermutlich eine Möglichkeit.

Axios direkt zu verwenden übersteigt vermutlich meine Möglichkeiten

@samson71 Danke für den Vorschlag: Ja, so einen ähnlichen Workaround mache ich ja bereits mit dem Lichtsensor. Derzeit habe ich dort keine Steckdose mit Leistungsmessung angeschlossen.

Ich hatte mich allerdings gefragt, ob es eventuell eine elegante codebasierte Lösung statt eines Workarounds gibt.

Hallo,

ich frage per HttpGet den Wechselrichter apsystems ez1-m ab. Da dieser Mikrowechselrichter erst bei einem gewissen Lichteinfall startet und nicht fremdversorgt ist, antwortet dessen Webserver bei Dunkelheit nicht.

Das wiederum sorgt beim Pollen für hässliche Fehlerlogs, die ich bisher auch mit üblichen Try-Catch-Bemühungen nicht lösen kann und über Nacht das Fehlerprotokoll füllen:

script.js.Balkonkraftwerk: httpGet(url=http://192.168.178.58:8050/getOutputData, error=timeout of 2000ms exceeded)

Hier der ansonsten (im Hellen...) funktionierende Code:

httpGet('http://192.168.178.58:8050/getOutputData', { timeout: 2000 }, (err, response) => {

            if (err) 
            {            
                setState('0_userdata.0.Balkonkraftwerk.Current_Combined_Power_W'/*Current Combined Power W*/, 0);
            }
            else if (response.statusCode == 200) 
            {
                const resObj = JSON.parse(response.data);
    
                setState('0_userdata.0.Balkonkraftwerk.Current_Combined_Power_W'/*Current Combined Power W*/, resObj.data.p1 + resObj.data.p2);
            }
        });

Nach etwas Recherche deutet sich an, dass Try-Catch o.ä. hier deshalb nicht funktioniert, weil die eigentliche Logmeldung innerhalb von HttpGet während der asynchronen Abarbeitung erzeugt wird:

https://www.heise.de/hintergrund/Einfuehrung-in-die-asynchrone-JavaScript-Programmierung-2752531.html

Mit welchem programmiertechnischem Kunstgriff ließen sich die obigen Logeinträge daher vermeiden?

Wäre dankbar für Vorschläge, da meine Javascript-Kenntnisse eher überschaubar sind...

Bisher nutze ich einen ohnehin verfügbaren Lichtsensor als Workaround für die Annahme, wann der Mikrowechselrichter wohl gestartet sein müsste. Ist aber genauso wie ein vorheriger Ping o.ä. auf den Webserver irgendwie keine schöne Lösung...