MQTT error im Log vom EIBPC2

[PharaDOS]

Moin,

ich hab seit einigerzeit immer wieder diesen fehler im Log:

9.2.2025, 23:46:04	25185 (0x6261)	mqttclient($localhost$,1883u16,AUS,MQTTUser,MQTT..	ERR_MQTT_CLIENT_CONNECT_ERR	0x2501
9.2.2025, 21:22:26	25185 (0x6261)	mqttclient($localhost$,1883u16,AUS,MQTTUser,MQTT..	ERR_ERRNO(32)	0x0820
9.2.2025, 20:25:38	25185 (0x6261)	mqttclient($localhost$,1883u16,AUS,MQTTUser,MQTT..	ERR_ERRNO(32)	0x0820

9.2.2025, 18:17:51	25185 (0x6261)	mqttclient($localhost$,1883u16,AUS,MQTTUser,MQTT..	ERR_MQTT_CLIENT_CONNECT_ERR	0x2501
9.2.2025, 18:03:03	25185 (0x6261)	mqttclient($localhost$,1883u16,AUS,MQTTUser,MQTT..	ERR_MQTT_CLIENT_CONNECT_ERR	0x2501
9.2.2025, 17:01:33	25185 (0x6261)	mqttclient($localhost$,1883u16,AUS,MQTTUser,MQTT..	ERR_MQTT_CLIENT_CONNECT_ERR	0x2501

Was bedeuten sie ?

[foobar0815]

ERR_ERRNO(32) heisst, dass die Verbindung abgebrochen ist. Da der Broker lokal läuft, ist der vielleicht überlastet?

[PharaDOS]

Tja, wie erkenne ich überlast, das problem hatte ich früher nicht, seit der neuen Firmware habe ich das gefühl das der EIBPC2 auch nicht mehr so rund läuft.

[PharaDOS]

Hallo
Vielen Dank für den super tollen Support,

Das Problem wurde durch enerfranz gefunden, die Überlastung entstanden durch parsejson Anfragen die das System ueberlasteten.

habe nun die parsejson Anfragen angepasst und die strings verkleinert.

[PharaDOS]

Ich stell mir nun die frage, sind 60 HTTP request (Hue Lampen) besser oder ein HTTP mit 60 ParseJson die dann den String splitten.

[Jukom]

habe nun die parsejson Anfragen angepasst und die strings verkleinert.

wie hast du die verkleinert?

meine json strings von den shellys sind zwischen 80 und 433 Zeichen lang. Daher muss ich doch immer den c1400 Typ verwenden

[PharaDOS]

bei mir war 40000 :-) und wenn du da dein 10 mal einen json drauf packts, geht der EibPC2 in die knie.
somit habe ich dann z.b. 40 lampen a 1000 gemacht und dann dort je lampe 10 abfragen. damit kann er umgehen

[Jukom]

sry das war eine voreilige Frage. Handbuchlesen hilft. Hab nun alle json strings auf c500 gekürzt

[foobar0815]

Es geht weniger um die statische Länge (zB 1400) sondern mehr um die tatsächliche, die beim parsen eine Rolle spielt.

Im Experten kannst du beliebige Längen verwenden (c1-c65534). c0 kannst du für "konstante" Strings mit Initialisierung nutzen, z.B. bei IPs/Hosts: $192.168.1.1$c0, dann wird die Länge durch den Parser selbst festgelegt.

Hier war das Problem aber das Parsen eines langen Strings für viele unterschiedliche Elemente, also sinngemäß:

status = $ganz großes JSON-Objekt$

if change(status) then {
 wert1 = parsejson(status, $/a/b/1$);
 wert2 = parsejson(status, $/a/b/2$);
 wert3 = parsejson(status, $/a/b/3$);
...
 wert100 = parsejson(status, $/c/d/1$);
 ...
} endif

Hier ist folgendes es deutlich effizienter:

status = $ganz großes JSON-Objekt$

if change(status) then {
statusA  = parsejson(status, $/a$);
} endif

if change(statusA) then {
statusB  = parsejson(status,A $/b$);
} endif​

if change(statusB) then {
wert1  = parsejson(statusB, $/1$);
wert2  = parsejson(statusB, $/2$);
wert3  = parsejson(statusB, $/3$);
...
} endif​​​​​​

Natürlich alles immer im Verhältnis zum Aufwand.

Edit: Variablennamen korrigiert

[EPIX]

gute Anregung, aber was ist

zStatus

[Jukom]

.

gute Anregung, aber was ist

nur ein Beispiel für einen sehr langen Json String aus welchem unterschiedliche Werte entnommen werden sollen

Aber das Optimierungsbeispiel verstehe ich jetzt nicht.
Status B und die Werte 1 bis n wird ja nur geparst wenn sich status A ändert. Aber das ist ja nich immer der Fall

{"id":0,"a_current":0.315,"a_voltage":236.7,"a_act _power":32.7,"a_aprt_power":74.6,"a_pf":0.45,"a_fr eq":50.0,"b_current":0.260,"b_voltage":236.8,"b_ac t_power":27.9,"b_aprt_power":61.7,"b_pf":0.46,"b_f req":50.0,"c_current":0.238,"c_voltage":237.2,"c_a ct_power":35.7,"c_aprt_power":56.5,"c_pf":0.64,"c_ freq":50.0,"n_current":null,"total_current":0.812, "total_act_power":96.343,"total_aprt_power":192.75 3, "user_calibrated_phase":[]}

Bei diesem Json z.B. können sich ja die unterschiedlichen Werte unabhägig voneinander ändern

[foobar0815]

Geht nur, wenn die Werte tiefer in der Objekthierarchie liegen.

Bei manchen Geräten lässt sich auch das Format anpassen, von JSON-Objekten zu einzelnen Werten

[PharaDOS]

[QUOTE=foobar0815;n2022594]Es geht weniger um die statische Länge (zB 1400) sondern mehr um die tatsächliche, die beim parsen eine Rolle spielt.

Im Experten kannst du beliebige Längen verwenden (c1-c65534). c0 kannst du für "konstante" Strings mit Initialisierung nutzen, z.B. bei IPs/Hosts: $192.168.1.1$c0, dann wird die Länge durch den Parser selbst festgelegt.

Hier war das Problem aber das Parsen eines langen Strings für viele unterschiedliche Elemente, also sinngemäß:

status = $ganz großes JSON-Objekt$

if change(status) then {
wert1 = parsejson(status, $/a/b/1$);
wert2 = parsejson(status, $/a/b/2$);
wert3 = parsejson(status, $/a/b/3$);
...
wert100 = parsejson(status, $/c/d/1$);
...
} endif

Hier ist folgendes es deutlich effizienter:

status = $ganz großes JSON-Objekt$

if change(status) then {
statusA = parsejson(status, $/a$);
} endif

if change(statusA) then {
statusB = parsejson(status,A $/b$);
} endif​

if change(statusB) then {
wert1 = parsejson(statusB, $/1$);
wert2 = parsejson(statusB, $/2$);
wert3 = parsejson(statusB, $/3$);
...
} endif​​​​​​

wie gehe ich damit um wenn der wert3 z.b. nicht immer im json ist. dann flapped ja meine variable(wert3) .
ich würde vermuten das ich immer wert3temp machen müsste und dann abfragen ob nicht leer und dann in wert3 schreiben. so das ich immer den letzten wert3 habe ?

[Jukom]

wie gehe ich damit um wenn der wert3 z.b. nicht immer im json ist.

Wert 1 bis Wert n auch mit "if change()" prüfen und dementsprechend verwerten

[PharaDOS]

Hatte gehofft das es eleganter geht, da müsste ich ja jeden jsonparse neinzeln verpacken