Beiträge von nicx*

OH WAS FÜR EIN MIST! Ich habe es (zufälligerweise) gelöst...

Es lag im Grunde doch an Unifi: Ich nutze eine UDM Pro mit aktiviertem Threat Management. Ich habe vor lauter Verzweiflung dieses Threat Management deaktiviert: Plötzlich funktionierten die Shelly-Actions wieder?! Das noch viel Seltsamere kommt jetzt aber: Nach Wiedereinschalten des Threat Managements funktionieren die Shelly-Actions immer noch

Eventuell hätte ein Reboot oder ein Reprovisioning des UDM Pro ebenfalls gereicht. Es scheint als ob sich hier intern irgend etwas verhakt hatte. Mich wundert zwar immer noch dass dieses Problem so in der Form innerhalb eines Netztes überhaupt bestand, aber seis drum. Man muss ja nicht immer alles mit Logik erklären können/wollen

Jetzt bin ich mal gespannt ob das Problem irgendwann wieder auftaucht. Erst einmal bin ich glücklich

dewaldo um das auszuschliessen habe ich mich natürlich auch schon mit einem Client ins gleiche Netz-Segment "gesetzt". Auch hier funktioniert es wunderbar. Nur die Shellys mögen nicht.

PS: Ich nutze Unifi als Netzwerklösung, Veränderungen am Setup gab es schon Jahre nicht mehr. Die Shelly haben aber für Monate/Jahre wunderbar funktioniert. Sie haben Ihren Dienst ja erst mit Firmware-Update eingestellt. Blöderweise hilft ein Downgrade aber nicht?!

Ich bin echt ratlos...

und als ergänzung bzgl. des IP-Range-Themas: Sowohl die Shellys, als auch das Nuki, sitzen im gleichen IP-Range (192.168.1.x/24). Die Connection die man da sieht ist schlicht die IP meines Clients über den ich per Browser das Log auslese

was ich inzwischen herausgefunden habe: wenn man mqtt aktiviert, dann sieht die fehlermeldung anders aus. da wird dann nicht mehr versucht für actions die cloud_queue zu nutzen. steht so auch dran an der mqtt option WARNING ("If you enable MQTT - actions via Cloud connection will be disabled!"). ist aber komisch, da ich bei mir die cloud nicht nutze. das scheint ein bug zu sein.

nun gut, hat wohl aber nichts direkt mit meinem problem zu tun. das problem besteht nämlich weiterhin, aber die logmeldung ist eben eine andere:

163804712 action_url_queue.c:126  Fetching http://192.168.1.25:8080/lockAction?nukiId=*******&token=*****&action=3
164287490 mgos_http_server.c:180  0x3fff303c HTTP connection from 192.168.0.172:59825
164304689 json.c:426              RAM: 51584 total, 35880 free
165401852 ix3.c:533               temperature 60.737508
166312312 action_url_queue.c:67   ACTION TIMEOUT

same probleme here with 2 shelly i3. dagumar did you solve it?

same here with two shelly i3. @backslashv did you solve it?

jeztt habe ich das nochmal mit aktiviertem log nachgestellt, mich macht das "waiting for action_url_queue" stutzig. scheint so als ob der befehl zwar getriggert wird aber dann in irgendeiner queue versauert.

kann vielleicht mal jemand von euch das selbe nachstellen mit aktiviertem log und dann hier die ergebnisse posten? danke

193320186832 mgos_http_server.c:180  0x3fff2b1c HTTP connection from 192.168.0.150:56158
193320195228 json.c:420              RAM: 51648 total, 37668 free
193320365134 ix3.c:533               temperature 73.295018
193324318446 shelly_switch.c:168     switches: 00000001
193324321173 ix3.c:314               ==== physical inputs changed: 0x07 -> 0x01 is_initial=0
193324324464 ix3.c:498               ==== input 1 (switch 2) has new logical state: 0
193324327616 ix3.c:498               ==== input 2 (switch 3) has new logical state: 0
193324606465 shelly_switch.c:168     switches: 00000005
193324609208 ix3.c:314               ==== physical inputs changed: 0x01 -> 0x05 is_initial=0
193324615410 shelly_switch.c:168     switches: 00000007
193324618124 ix3.c:314               ==== physical inputs changed: 0x05 -> 0x07 is_initial=0
193325113171 shelly_multipush.c:297  ==== registered multipush sequence "shortpush" (cnt=4) on input 2 (switch 3)
193325121512 shelly_multipush.c:297  ==== registered multipush sequence "shortpush" (cnt=4) on input 1 (switch 2)
193325124891 action_url_queue.c:107  Fetching http://192.168.1.52/roller/0?go=close
193325130945 cloud_common.c:1391     waiting for action_url_queue
193325234164 cloud_common.c:1391     waiting for action_url_queue
193325365016 ix3.c:533               temperature 73.295018
193325370619 cloud_common.c:1391     waiting for action_url_queue
193325474224 cloud_common.c:1391     waiting for action_url_queue
193325577249 cloud_common.c:1391     waiting for action_url_queue
193325680232 cloud_common.c:1391     waiting for action_url_queue
193325783770 cloud_common.c:1391     waiting for action_url_queue
193325886784 cloud_common.c:1391     waiting for action_url_queue
193325989763 cloud_common.c:1391     waiting for action_url_queue
193326092889 cloud_common.c:1391     waiting for action_url_queue
193326196568 cloud_common.c:1391     waiting for action_url_queue
193326285235 mgos_http_server.c:180  0x3fff2784 HTTP connection from 192.168.0.150:56160
193326293707 json.c:420              RAM: 51648 total, 36672 free
193326332405 cloud_common.c:1391     waiting for action_url_queue
193326435974 cloud_common.c:1391     waiting for action_url_queue
193326538967 cloud_common.c:1391     waiting for action_url_queue

dewaldo der button ist (und war schon immer) als "momentary" konfiguriert. daher ist der input nicht "aktiv", sondern eben "on". beim nächsten tastendruck geht er auf "off". das ist schon richtig so, muss so sein wenn man "short/long pressed" actions verwenden möchte. im button mode "toggle switch" gehen hingegen nur switch on/off actions.

egal welche variante ich nutze, die i3's lösen die actions nicht aus.

hier nun doch noch ein screenshot eines weiteren problematischen i3:

wie gesagt: url funktioniert einwandfrei im browser. Am Input1 selbst sehe ich dass er korrekt auf den Tastendruck reagiert (blauer ring geht an und aus). nur der i3 führt die action nicht aus

ja kalr, per browser funktionierts einwandfrei. es word auch kein anderer shelly angesprochen, sondern ein nuki schloss.

ich nutze die actions auch mit anderen shellys (1 & 2.5) ohne probleme. nir die i3 (und eben beide) haben das problem.

screenshot schicke ich lieber mal nicht, sonst könntest du mit dem token meine tür öffnen 😂

gibts denn irgendwie erweiterte logging möchlichleien beims i3 um zu sehen ob er überhaupt die action triggert?

so nach dem downgrade auf 1.11.5 habe ich mal 1 Tag gewartet, und wie erwartet hat sich nichts getan. Problem beibt bestehen

Gibts Ideen?

Ich habe nun das gleiche Problem mit zwei Stück i3: Beide haben seit Monaten klaglos funktioniert. Leider habe ich dann ein FW Update gemacht auf die aktuellste 1.11.8, seither werden die Actions nicht mehr ausgeführt.

Ein Downgrade auf verschiedene alte Versionen führen ebenfalls nicht mehr zum Erfolg.

Was genau könnte ich tun, damit die Actions wieder funktionieren?

newusermm was genau meinst du mit "man muss längere Zeit warten"?

Meines Wissens geht das aktuell nur mit einem Drittsystem, also nicht mit der Shelly App.

super, genau das was ich bzgl. saldieren gesucht habe und in meinen ganzen post versucht hatte zu erklären... mit einer "externen" lösung ist es schlicht egal was der shelly kann oder auch nicht werde ich ebenfalls so umsetzn. danke HdH50

buuuuuuuh!

Home Assistant!

also anscheinend bin ich einfach zu doof, oder wir reden aneinander vorbei. ich hoffe noch es ist "nur" zweiteres

deine grafik zeigt die direkten werte des shelly 3em an, oder?

das will ich doch gar nicht. ich will lediglich die aktuelle power pro phase des shellys mit HA auslesen und ignoriere alle anderen werte des shellys. diese 3 werte addiere ich dann innerhalb von HA. der shelly ist da schon komplett raus. um in deinem beispiel zu bleiben: der shelly liefert als summenwert 400w (was falsch ist), innerhalb von HA liefert aber der HA-template-sensor -200W (was richtig ist). ich saldiere also selber mithilfe von Home assistant.

sag mir jetzt bitte nicht das doch ersteres zutrifft, ich also zu doof bin

Danke für die Erklärung, aber das hilft mir leider noch nicht bei meinem Knoten im Kopf. Daher noch ein Versuch:

Ich brauche/möchte doch gar nicht den Shelly für die korrekte Berechnung wenn ich Home Assistant nutzen kann. Die Summe der 3 Phasen (in deinem Beispiel 100+100-400) sind doch genau die -200W. Hierzu reicht ein ganz simpler Template Sensor in Home Assistant. Der Shelly reicht mir also als "doofer" Wertübermittler für jede Phase. Und das es eine Einspeisung ist erkenne ich am negativen Vorzeichen. Bei Bezug würde der Sensor positive Werte haben.

Den Gesamtverbrauch würde ich über einen Utility_Meter Sensor in HA abbilden, der dann eben wiederum den HA-Template-Sensor als Quelle nutzt.

Oder bin ich immer noch schief gewickelt und das funktioniert nicht?

Ich sehe das nicht anders, ich habe das Problem wohl schlicht noch nicht verstanden

Warum ist das nicht Sinn der Sache? Für mich schon, da ich Home Assistant einsetze und genau solch ein Dashboard nutzen möchte

Bevor ich mich Monate/Jahre über die fehlende Funktionalität des 3EM aufrege (was ich nicht tue) nehme ich einfach ein wenig Geld in die Hand (was in Relation zu den PV-Kosten nahezu vernachlässigbar ist) und kaufe 2 3EMs, Thema gelöst