Habe jetzt nicht die gleichen Leuchten im Einsatz, habe aber auch schon schlechte Erfahrung mit LEDvance gemacht. Normale "Glühbirne" E27 LED alle 2 Tage kaputt in einer Außenleuchte ohne Dimmer, einfach nur an/aus.
Habe jetzt auf Phillips umgebaut und die laufen schon fast ein Jahr.
Vlt mal bei Philips nach passendem Leuchtmittel suchen.
Phase B zeigt auch keine Spannung.
Evtl. die Sicherung raus für B?
Wenn man nach dem Shelly 1 noch ein Relais mit Wechslerkontakt setzen würde, würde es auch gehen. Dann wäre z.B. Shelly an=Heizbetrieb und Shelly aus=Kühlbetrieb.
Also bei meinem Shelly 1 funktioniert Sonnenauf- und -untergang definitv ohne Cloudanmeldung. Internetzugang hat er und somit die Uhrzeit und die Geoposition hat er sich auch bis auf wenige Meter genau automatisch gezogen. Es mag sein, dass er sich diese Daten von einem Shelly-Server holt, aber definitiv braucht er nicht die Cloudanmeldung.
Hallo zusammen,
ich habe einen Shelly 1 als Zeitschaltuhr installiert. Schaltbedingung "Sunset ON", "22Uhr OFF".
Das scheint soweit zu funktionieren, leider bin ich nicht zu den Schaltzeiten vor Ort.
Nun habe ich versucht, über das Logfile rauszufinden, wann der Ausgang jetzt genau bei "Sunset" schaltet.
Das Logfile unter <IP>/debug/log1 gibt aber nichts her, wenn ich morgens in das Logfile schaue, zeigt er mir Werte von 3 Uhr morgens, aber nicht weiter zurück.
Unter <IP>/debug/log2 oder log3 sehe ich noch andere Werte. Gibt es irgendwo eine Auflistung, was diese logfiles aussagen?
Gibt es eine Möglichkeit, wie ich den Schaltpunkt meines Shellys mit Zeitstempel sehen kann? Ist das Logfile immer voll mit diesen "minute-tick"?
578573911541 shelly_sntp.c:433 minute tick at 03:14:00
578633764340 shelly_sntp.c:433 minute tick at 03:15:00
578693620712 shelly_sntp.c:433 minute tick at 03:16:00
578753598852 shelly_sntp.c:433 minute tick at 03:17:00
578813666705 shelly_sntp.c:433 minute tick at 03:18:00
578873652602 shelly_sntp.c:433 minute tick at 03:19:00
578933729820 shelly_sntp.c:433 minute tick at 03:20:00
578993726651 shelly_sntp.c:433 minute tick at 03:21:00
579053661186 shelly_sntp.c:433 minute tick at 03:22:00
579113745456 shelly_sntp.c:433 minute tick at 03:23:00
579173790092 shelly_sntp.c:433 minute tick at 03:24:00
579233755926 shelly_sntp.c:433 minute tick at 03:25:00
579293652524 shelly_sntp.c:433 minute tick at 03:26:00
579342505590 mgos_wifi_sta.c:737 Avg RSSI -72, will scan for a better AP
579342522753 esp_main.c:138 SDK: sl
579344714226 esp_main.c:138 SDK: scandone
579344723832 esp_main.c:138 SDK: usl
579344733276 mgos_wifi_sta.c:562 Best AP is not much better (RSSI -70 vs -72)
579353733668 shelly_sntp.c:433 minute tick at 03:27:00
579413720398 shelly_sntp.c:433 minute tick at 03:28:00
579473731517 shelly_sntp.c:433 minute tick at 03:29:00
579533828267 shelly_sntp.c:433 minute tick at 03:30:00
579593698418 shelly_sntp.c:433 minute tick at 03:31:00
579653769445 shelly_sntp.c:433 minute tick at 03:32:00
579713829703 shelly_sntp.c:433 minute tick at 03:33:00
579773631700 shelly_sntp.c:433 minute tick at 03:34:00
579833784508 shelly_sntp.c:433 minute tick at 03:35:00
579893715540 shelly_sntp.c:433 minute tick at 03:36:00
579944739930 mgos_wifi_sta.c:737 Avg RSSI -72, will scan for a better AP
579944758292 esp_main.c:138 SDK: sl
579946879696 esp_main.c:138 SDK: scandone
579946889938 esp_main.c:138 SDK: usl
579946898169 mgos_wifi_sta.c:560 Current AP is best AP
579953601688 shelly_sntp.c:433 minute tick at 03:37:00
580013791707 shelly_sntp.c:433 minute tick at 03:38:00
580073770753 shelly_sntp.c:433 minute tick at 03:39:00
580133777409 shelly_sntp.c:433 minute tick at 03:40:00
580193840980 shelly_sntp.c:433 minute tick at 03:41:00
580253819645 shelly_sntp.c:433 minute tick at 03:42:00
580313722549 shelly_sntp.c:433 minute tick at 03:43:00
580373603475 shelly_sntp.c:433 minute tick at 03:44:00
580433711303 shelly_sntp.c:433 minute tick at 03:45:00
580493716778 shelly_sntp.c:433 minute tick at 03:46:00
580553820414 shelly_sntp.c:433 minute tick at 03:47:00
580561905200 mgos_wifi_sta.c:737 Avg RSSI -71, will scan for a better AP
580561922479 esp_main.c:138 SDK: sl
580564045113 esp_main.c:138 SDK: scandone
580564054627 esp_main.c:138 SDK: usl
580564062852 mgos_wifi_sta.c:560 Current AP is best AP
580613730905 shelly_sntp.c:433 minute tick at 03:48:00
580673838278 shelly_sntp.c:433 minute tick at 03:49:00
580733743785 shelly_sntp.c:433 minute tick at 03:50:00
580793643180 shelly_sntp.c:433 minute tick at 03:51:00
580853651708 shelly_sntp.c:433 minute tick at 03:52:00
580913611646 shelly_sntp.c:433 minute tick at 03:53:00
580973813160 shelly_sntp.c:433 minute tick at 03:54:00
581033766298 shelly_sntp.c:433 minute tick at 03:55:00
581093787687 shelly_sntp.c:433 minute tick at 03:56:00
581153754205 shelly_sntp.c:433 minute tick at 03:57:00
581213721284 shelly_sntp.c:433 minute tick at 03:58:00
581224069898 mgos_wifi_sta.c:737 Avg RSSI -71, will scan for a better AP
581224076973 esp_main.c:138 SDK: sl
581226199053 esp_main.c:138 SDK: scandone
581226210568 esp_main.c:138 SDK: usl
581226298620 mgos_wifi_sta.c:560 Current AP is best AP
581273603611 shelly_sntp.c:433 minute tick at 03:59:00
581333801072 shelly_sntp.c:433 minute tick at 04:00:00
581393780516 shelly_sntp.c:433 minute tick at 04:01:00
581453801864 shelly_sntp.c:433 minute tick at 04:02:00
581513792406 shelly_sntp.c:433 minute tick at 04:03:00
581573756778 shelly_sntp.c:433 minute tick at 04:04:00
581633707781 shelly_sntp.c:433 minute tick at 04:05:00
581693774224 shelly_sntp.c:433 minute tick at 04:06:00
581753828556 shelly_sntp.c:433 minute tick at 04:07:00
581813653232 shelly_sntp.c:433 minute tick at 04:08:00
581856305711 mgos_wifi_sta.c:737 Avg RSSI -71, will scan for a better AP
581856393572 esp_main.c:138 SDK: sl
581858514950 esp_main.c:138 SDK: scandone
581858524615 esp_main.c:138 SDK: usl
581858532871 mgos_wifi_sta.c:560 Current AP is best AP
581873789198 shelly_sntp.c:433 minute tick at 04:09:00
581933789409 shelly_sntp.c:433 minute tick at 04:10:00
581993789360 shelly_sntp.c:433 minute tick at 04:11:00
582053789397 shelly_sntp.c:433 minute tick at 04:12:00
582113789572 shelly_sntp.c:433 minute tick at 04:13:00
582173789275 shelly_sntp.c:433 minute tick at 04:14:00
582233789174 shelly_sntp.c:433 minute tick at 04:15:00
582293789372 shelly_sntp.c:433 minute tick at 04:16:00
582353789137 shelly_sntp.c:433 minute tick at 04:17:00
582413789570 shelly_sntp.c:433 minute tick at 04:18:00
582458539791 mgos_wifi_sta.c:737 Avg RSSI -71, will scan for a better AP
582458557050 esp_main.c:138 SDK: sl
582460679182 esp_main.c:138 SDK: scandone
582460689947 esp_main.c:138 SDK: usl
582460698300 mgos_wifi_sta.c:562 Best AP is not much better (RSSI -71 vs -72)
582473737338 shelly_sntp.c:433 minute tick at 04:19:00
582533774638 shelly_sntp.c:433 minute tick at 04:20:00
582593689817 shelly_sntp.c:433 minute tick at 04:21:00
582653734752 shelly_sntp.c:433 minute tick at 04:22:00
582713742040 shelly_sntp.c:433 minute tick at 04:23:00
582773676529 shelly_sntp.c:433 minute tick at 04:24:00
582833702568 shelly_sntp.c:433 minute tick at 04:25:00
582893600436 shelly_sntp.c:433 minute tick at 04:26:00
582953757599 shelly_sntp.c:433 minute tick at 04:27:00
583013763548 shelly_sntp.c:433 minute tick at 04:28:00
583060705320 mgos_wifi_sta.c:737 Avg RSSI -72, will scan for a better AP
583060722637 esp_main.c:138 SDK: sl
583062845185 esp_main.c:138 SDK: scandone
583062855468 esp_main.c:138 SDK: usl
583062863881 mgos_wifi_sta.c:562 Best AP is not much better (RSSI -70 vs -72)
583073773915 shelly_sntp.c:433 minute tick at 04:29:00
583133724151 shelly_sntp.c:433 minute tick at 04:30:00
583193636565 shelly_sntp.c:433 minute tick at 04:31:00
583253657520 shelly_sntp.c:433 minute tick at 04:32:00
583313664679 shelly_sntp.c:433 minute tick at 04:33:00
583373669526 shelly_sntp.c:433 minute tick at 04:34:00
583433674536 shelly_sntp.c:433 minute tick at 04:35:00
583493716307 shelly_sntp.c:433 minute tick at 04:36:00
583553684519 shelly_sntp.c:433 minute tick at 04:37:00
583613604065 shelly_sntp.c:433 minute tick at 04:38:00
583662871741 mgos_wifi_sta.c:737 Avg RSSI -71, will scan for a better AP
583662891027 esp_main.c:138 SDK: sl
583665016121 esp_main.c:138 SDK: scandone
583665026789 esp_main.c:138 SDK: usl
583665118338 mgos_wifi_sta.c:560 Current AP is best AP
583673776585 shelly_sntp.c:433 minute tick at 04:39:00
583733638125 shelly_sntp.c:433 minute tick at 04:40:00
583793742066 shelly_sntp.c:433 minute tick at 04:41:00
583853697122 shelly_sntp.c:433 minute tick at 04:42:00
583913702181 shelly_sntp.c:433 minute tick at 04:43:00
583973707791 shelly_sntp.c:433 minute tick at 04:44:00
584033748813 shelly_sntp.c:433 minute tick at 04:45:00
584093732045 shelly_sntp.c:433 minute tick at 04:46:00
584153723493 shelly_sntp.c:433 minute tick at 04:47:00
584213706436 shelly_sntp.c:433 minute tick at 04:48:00
584273836573 shelly_sntp.c:433 minute tick at 04:49:00
584333753223 shelly_sntp.c:433 minute tick at 04:50:00
584385125206 mgos_wifi_sta.c:737 Avg RSSI -71, will scan for a better AP
584385133388 esp_main.c:138 SDK: sl
584387255461 esp_main.c:138 SDK: scandone
584387265764 esp_main.c:138 SDK: usl
584387274136 mgos_wifi_sta.c:560 Current AP is best AP
584393671723 shelly_sntp.c:433 minute tick at 04:51:00
584453615654 shelly_sntp.c:433 minute tick at 04:52:00
584513605449 shelly_sntp.c:433 minute tick at 04:53:00
584573749401 shelly_sntp.c:433 minute tick at 04:54:00
584633693021 shelly_sntp.c:433 minute tick at 04:55:00
584693800577 shelly_sntp.c:433 minute tick at 04:56:00
584753621595 shelly_sntp.c:433 minute tick at 04:57:00
584813642192 shelly_sntp.c:433 minute tick at 04:58:00
584873618343 shelly_sntp.c:433 minute tick at 04:59:00
584933617600 shelly_sntp.c:433 minute tick at 05:00:00
584987281114 mgos_wifi_sta.c:737 Avg RSSI -74, will scan for a better AP
584987288289 esp_main.c:138 SDK: sl
584989410303 esp_main.c:138 SDK: scandone
584989421134 esp_main.c:138 SDK: usl
584989431573 mgos_wifi_sta.c:575 Trying to switch to cc:db:93:98:f7:61 (RSSI -73 -> -64)
584989436935 esp_main.c:138 SDK: state: 5 -> 0 (0)
584989442670 esp_main.c:138 SDK: rm 0
584989447981 esp_main.c:138 SDK: pm close 7
584989457224 mgos_wifi.c:70 WiFi STA: Disconnected, reason: 8
584989536654 esp_main.c:138 SDK: sleep enable,type: 2
584989543781 mgos_net.c:84 WiFi STA: disconnected
584989549878 shelly.c:312 WiFi status=1313166336; mode=1
584989793704 coiot.c:491 Coap listener 0x3ffef83c is closed!
584989798881 coiot.c:616 coap_connect, WIFI status=1313166336 mode=1
584992537716 mgos_wifi_sta.c:610 Trying hdisproduktion AP cc:db:93:98:f7:61 ch 1 RSSI -64 cfg 0 att 1
584992544948 esp_wifi.c:273 WiFi STA IP: 172.31.2.234/255.255.252.0 gw 172.31.1.1
584992555244 mgos_net.c:89 WiFi STA: connecting
584992652638 esp_main.c:138 SDK: scandone
584992659859 esp_main.c:138 SDK: state: 0 -> 2 (b0)
584992668343 esp_main.c:138 SDK: state: 2 -> 3 (0)
584992732157 esp_main.c:138 SDK: state: 3 -> 5 (10)
584992737534 esp_main.c:138 SDK: add 0
584992742803 esp_main.c:138 SDK: aid 1
584992749441 esp_main.c:138 SDK: cnt
584992774535 esp_main.c:138 SDK:
584992779445 esp_main.c:138 SDK: connected with hdisproduktion, channel 1
584992786417 esp_main.c:138 SDK: ip:172.31.2.234,mask:255.255.252.0,gw:172.31.1.1
584992794235 mgos_wifi.c:83 WiFi STA: Connected, BSSID cc:db:93:98:f7:61 ch 1 RSSI -74
584992800055 esp_main.c:138 SDK: sleep enable,type: 2
584992809115 mgos_wifi_sta.c:697 Saving AP hdisproduktion cc:db:93:98:f7:61 ch 1
584993163317 mgos_sys_config.c:323 Saved to conf9.json
584993174976 mgos_net.c:93 WiFi STA: connected
584993181589 mgos_net.c:103 WiFi STA: ready, IP 172.31.2.234, GW 172.31.1.1, DNS 172.31.1.91, NTP 0.0.0.0
584993188962 shelly.c:312 WiFi status=1313166339; mode=1
584993198427 coiot.c:616 coap_connect, WIFI status=1313166339 mode=1
584993204899 coiot.c:646 coiot: multicast group 224.0.1.187:5683
584993210181 coiot.c:603 coiot: CONNECTED!!
584993797094 shelly_sntp.c:433 minute tick at 05:01:00
585002749386 esp_main.c:138 SDK: pm open,type:2 0
585053802148 shelly_sntp.c:433 minute tick at 05:02:00
585113802192 shelly_sntp.c:433 minute tick at 05:03:00
585115061875 mgos_sntp.c:98 SNTP query to 172.31.0.130
585115111903 mgos_sntp.c:60 SNTP reply from 172.31.0.130: time 1664852582.372488, local 1664852581.892024, delta 0.480464
585115117954 shelly_sntp.c:387 got time, delta=0.473587
585232803774:1664852700060033 shelly_sntp.c:433 minute tick at 05:05:00
585293053351 shelly_sntp.c:433 minute tick at 05:06:00
585353053240 shelly_sntp.c:433 minute tick at 05:07:00
585413053342 shelly_sntp.c:433 minute tick at 05:08:00
585473053017 shelly_sntp.c:433 minute tick at 05:09:00
585533053161 shelly_sntp.c:433 minute tick at 05:10:00
585592553874 mgos_wifi_sta.c:737 Avg RSSI -75, will scan for a better AP
585592571165 esp_main.c:138 SDK: sl
585592812375 shelly_sntp.c:433 minute tick at 05:11:00
585594694987 esp_main.c:138 SDK: scandone
585594704697 esp_main.c:138 SDK: usl
585594713330 mgos_wifi_sta.c:560 Current AP is best AP
585652900345 shelly_sntp.c:433 minute tick at 05:12:00
585712867894 shelly_sntp.c:433 minute tick at 05:13:00
585772808793 shelly_sntp.c:433 minute tick at 05:14:00
585832845707 shelly_sntp.c:433 minute tick at 05:15:00
585892875862 shelly_sntp.c:433 minute tick at 05:16:00
585952873859 shelly_sntp.c:433 minute tick at 05:17:00
586013033908 shelly_sntp.c:433 minute tick at 05:18:00
586073026393 shelly_sntp.c:433 minute tick at 05:19:00
586132884151 shelly_sntp.c:433 minute tick at 05:20:00
586192867258 shelly_sntp.c:433 minute tick at 05:21:00
586194721419 mgos_wifi_sta.c:737 Avg RSSI -77, will scan for a better AP
586194732199 esp_main.c:138 SDK: sl
586196922527 esp_main.c:138 SDK: scandone
586196933603 esp_main.c:138 SDK: usl
586196942895 mgos_wifi_sta.c:575 Trying to switch to 68:3b:78:76:fc:21 (RSSI -77 -> -70)
586196948289 esp_main.c:138 SDK: state: 5 -> 0 (0)
586196954039 esp_main.c:138 SDK: rm 0
586196960494 esp_main.c:138 SDK: pm close 7
586196969304 mgos_wifi.c:70 WiFi STA: Disconnected, reason: 8
586196975606 esp_main.c:138 SDK: sleep enable,type: 2
586196982157 mgos_net.c:84 WiFi STA: disconnected
586196990079 shelly.c:312 WiFi status=1313166336; mode=1
586197232074 coiot.c:491 Coap listener 0x3ffef83c is closed!
586197237298 coiot.c:616 coap_connect, WIFI status=1313166336 mode=1
586199976574 mgos_wifi_sta.c:610 Trying hdisproduktion AP 68:3b:78:76:fc:21 ch 6 RSSI -70 cfg 0 att 1
586199982750 esp_wifi.c:273 WiFi STA IP: 172.31.2.234/255.255.252.0 gw 172.31.1.1
586199995267 mgos_net.c:89 WiFi STA: connecting
586202621801 esp_main.c:138 SDK: scandone
586202628590 mgos_wifi.c:70 WiFi STA: Disconnected, reason: 201
586202633568 mgos_wifi_sta.c:637 Connect failed
586202640082 esp_main.c:138 SDK: sleep enable,type: 2
586202647334 mgos_net.c:84 WiFi STA: disconnected
586204641595 mgos_wifi_sta.c:610 Trying hdisproduktion AP 68:3b:78:73:c2:01 ch 1 RSSI -71 cfg 0 att 1
586204647791 esp_wifi.c:273 WiFi STA IP: 172.31.2.234/255.255.252.0 gw 172.31.1.1
586204658150 mgos_net.c:89 WiFi STA: connecting
586204755542 esp_main.c:138 SDK: scandone
586204761683 esp_main.c:138 SDK: state: 0 -> 2 (b0)
586204769546 esp_main.c:138 SDK: state: 2 -> 3 (0)
586204779567 esp_main.c:138 SDK: state: 3 -> 5 (10)
586204786079 esp_main.c:138 SDK: add 0
586204791911 esp_main.c:138 SDK: aid 1
586204888144 esp_main.c:138 SDK: cnt
586204912793 esp_main.c:138 SDK:
586204917760 esp_main.c:138 SDK: connected with hdisproduktion, channel 1
586204925890 esp_main.c:138 SDK: ip:172.31.2.234,mask:255.255.252.0,gw:172.31.1.1
586204932667 mgos_wifi.c:83 WiFi STA: Connected, BSSID 68:3b:78:73:c2:01 ch 1 RSSI -72
586204938530 esp_main.c:138 SDK: sleep enable,type: 2
586204947141 mgos_wifi_sta.c:697 Saving AP hdisproduktion 68:3b:78:73:c2:01 ch 1
586205341453 mgos_sys_config.c:323 Saved to conf9.jsonHallo zusammen,
in einem anderen Thread habe ich schonmal meine Probleme mit dem Shelly Plug erläutert. Dieser macht unregelmäßige Reboots und löscht somit seinen Speicher mit den Leistungsmessdaten.
In die Cloud soll das ganz nicht.
Gibt es eine "einfache" Lösung, diese Daten regelmäßig z.B. stündlich abzurufen und wegzuspeichern? Evtl auch mit einer Möglichkeit, fehlerhafte Werte z.B. nach einem Neustart geradezuziehen um daraus dann eine Tages/Wochen/Monatsauswertung zu zaubern?
Ich habe eigtl nicht die Muße, mich mit einem Raspberry zu beschäftigen und bräuchte etwas, das auf einem Windowssystem läuft. Entweder auf einem Server oder einfach ein kleiner Client-PC, der halt immer läuft.
Das ganze findet im betrieblichen Umfeld statt, somit ist ein Server eh vorhanden und separate Hardware könnte beschafft werden.
Ich habe schon ein bißchen mit Excel und der API-Abfrage rumgespielt, das würde mir grundsätzlich schon genügen an Daten. Nur eben automatisiert und ein bißchen intelligenter.
Schaltet der Plug S nur 1-polig ab? Dann könnt es sein, dass er so in der Dose steckt, dass der N geschalten wird. Vermutlich reagiert der Server dann nicht darauf.
Versuch doch mal den Plug 180° zu drehen, ob es dann geht.
Wo kommt denn deine Zuleitung her? Für mich sieht es so aus, als ob die braunen Adern die Zuleitung zum FI und zu deinem oberen Sicherungsblock sind. Der untere Sicherungsblock ist mittels Stromschiene mit dem FI verbunden. Würde erklären, warum sich der Messwert nur ändert, wenn du unten einen Verbraucher einschaltest: Zuleitung(braun) -> Messklemme 3EM -> FI -> Stromschiene -> LS-Schalter -> Verbraucher
Im oberen Block ist es dann: Zuleitung(braun) -> Messklemme 3EM -> FI -> zurück durch Messklemme 3EM -> LS-Schalter -> Verbraucher
Wenn das so ist, dann heben sich die Ströme gegenseitig auf in der Messklemme.
Ich würde sagen, die Adern mit den roten Aderendhülsen sind die Zuleitungsadern, erkennbar am N und am PE auf der Sammelschiene. Wenn du die Messklemmen nur um diese Adern machst, müsste es klappen.
Wenn du ein 2-poliges Relais verwendest könntest du passend zur Hauptversorgung auch die LED-Beleuchtung mit anschalten. Die leuchten dann halt immer, wenn das Gerät arbeitet, aber das wäre sicher zu verschmerzen.
Der Test im heimischen Stromnetz war dahingehend erfolgreich, dass der Shellyplug da tadellos funktioniert hat, während er in der Firma nicht mal 24h Uptime geschafft hat.
Also liegt es nicht am Plug, sondern daran, dass er empfindlich auf Netzstörungen reagiert.
Ich werde mal abwarten, was unsere zentrale Filterlösung an Ergebnissen bringt. Ein bißchen Hoffnung habe ich noch...
Also..
Ein Kollege aus der IT hat mal 3 Stück mit nach Hause genommen, die bei uns immer wieder den Fehler brachten. Da habe ich aber noch keine Rückmeldung.
Der Entstörfilter in der Verteilung kommt grundsätzlich wegen anderer Sachen, die Shellys profitieren im besten Fall mit davon.
Störungen in unserem Netz kommen allgemein durch die Anlagen, hier trägt jeder Anlagenteil mit seinen Frequenzumrichtern ein wenig zum gesamten bei. Jede Anlage in sich ist mit Sicherheit normkonform bezüglich Netzqualität, EMV etc., es summiert sich halt dann auf und wird über N/PE/Fundamenterder im gesamten Gebäude "verteilt".
Eine Untersuchung der Netzqualität ergab einen erhöhten Störbereich bei 8kHz-10kHz. Also recht hochfrequent. Vlt leitet das RC Glied nicht genug der Störung ab...
Tja. die finale Lösung war es wohl doch noch nicht...
Auch der umgebaute Plug hat gestern Abend einen Reboot gemacht.
Er hat deutlich länger durchgehalten als der originale, aber eben auch nicht zuverlässig stabil.
Habe jetzt mal beide Plug auf die *.8er Firmware upgedatet, mal schauen wie sich das auswirkt.
Habe den Ecomode erstmal deaktiviert, da der ja immer mal wieder Fehler verursacht.
Es gibt erste Erfolge.
Umgebauter Plug und Plug im Originalzustand am selben Stromkreis nebeneinander in einer Doppelsteckdose.
Umgebauter Plug speist einen Drucker, Original speist einen PC.
Heute um 12:30 Uhr Reboot vom Original, der Umbau lief durch (ach ja, beide Geräte befanden sich im Standby, also ist das Thema Last auch nicht relevant)
Da beide Plug direkt nebeneinander hängen ist das Thema WLAN gänzlich raus als Ursache.
Ich werde weiter testen und berichten.
Hallo,
mal wieder ein kleines Update von mir.
Ich habe jetzt passende RC Glieder bestellt, ähnlich wie die Original-Shelly. Also auch 100Ohm+100nF. Kommen von RS, anbei ein Link. Sind nicht ganz günstig, aber X2 und die richtige Bauform:
[product]https://de.rs-online.com/web/p/rc-netzw…ed%22%3Atrue%7D[/product]
Dadurch passen die nämlich mit minimalen Modifikationen in den Plug rein. Ich bin weiterhin flexibel, hab keine Steckdose zur "Messsteckdose" umgebaut und hoffe, dass es seinen Zweck erfüllen wird.
Ich werde testen und berichten.
Ach ja, bevor hier unqualifizierte Äußerungen auftauchen...ich bin Elektromeister und dementsprechend vom Fach und kann und darf solche Sachen.
Über Gewährleistung brauchen wir natürlich nicht mehr sprechen, die ist mir bei einem 20€ Artikel aber auch nicht wichtig.
Vielleicht auch testweise ein RC-Glied in der Steckdose installieren. Falls solche Störungen vorhanden sind, dann ist es natürlich gut diese zu filtern. Gerade bei großen Motoren kann ich es mir gut vorstellen. Ggf. ist es auch eine einzelne Maschine, die entstört werden sollte.
Wir haben keine wirklichen großen Antriebe, es sind viele kleine, die sich aufsummieren. Wir haben auch an anderen Stellen Ärger damit, darum jetzt der Einbau des Filters.
Ich wollte halt ungern an alle Steckdosen ran, das war ja der Charme vom Plug, dass man flexibel ist und das Ding einfach mal umstecken kann. Wenn ich jetzt wieder Steckdosen zu "Messsteckdosen" umbauen muss, ist das schon wieder sehr mühselig.
Btw, gibt es Empfehlungen für ein RC-Glied? Evtl was fertiges zum einbauen? Ich habe auch einen 1PM verbaut der auch dieses Verhalten zeigt, an den könnte ich natürlich so was fest installieren, da der in einer Unterverteilung sitzt.
Ich kann mal ein kleines Update geben, aber leider keine Lösung.
Ich hatte länger Kontakt mit dem Support von Alterco. Zuerst wurde ich auf die Logfiles verwiesen, leider sind die beim Plug nichtssagend. Dann wurde vermutet, dass es an Überlast liegt, wir nutzen alle Shelly Plug zur Strommessung an Druckern. Ja, so ein großer Drucker hat seine knapp 2kw Leistung, aber auch im Einschaltmoment bzw. im Drucken wird er niemals die 3,5kw überschreiten, vorallem haben wir auch kleinere Drucker dran. Der Reboot kam auch sehr oft über Nacht oder am WE, wo gar kein Druckvorgang lief weil keine Produktion. Dann habe ich einen PC an einen Plug gesteckt, um Überlast auszuschließen. Auch damit änderte sich nichts.
Die Antwort vom Support war daraufhin, schicken sie die Geräte zurück...
Was dem aber widerspricht ist der Fakt, das wir ca. 5-7 Stück in unserem Verwaltungsbereich laufen haben ohne Ausfälle. Die haben weit über 1500h Uptime.
Und da hängen auch große und kleine Drucker dran.
WLAN Probleme konnten wir auch ausschließen da aufgrund einer Produktionserweiterung das gesamte WLAN-Netz überprüft und erweitert wurde zwecks Ausleuchtung etc.
Der einzige Unterschied zwischen Verwaltung und Produktion ist, dass die Drucker der Verwaltung an EDV Steckdosen hängen, wo eine dicke USV dahintersteht.
Wir haben jetzt die Vermutung, dass durch die USV eventuelle Netzstörungen glattgebügelt werden und die normalen Stromkreise in der Produktion diese direkt an die Shellys weitergeben. Anscheinend sind die Dinger recht empfindlich für Störfrequenzen. Wir sind jetzt dabei und installieren einen zentralen Netzfilter, der solche Störfrequenzen kurzschließt und nicht ins Netz schickt. Hoffentlich begnügen sich auch die Shellys mit dieser Maßnahme und erledigen wieder zuverlässig ihren Dienst.
Nein, nichts was tagsüber nicht auch laufen würde.
Ich habe schonmal einen getauscht gegen einen anderen, der zeigte aber das gleiche Phänomen mit dem Reboot.
Selber Außenleiter könnte den gemeinsamen Ausfall erklären, da bin ich mir jetzt nicht ganz sicher. Aber ich hab die Ausfälle auch in ganz anderen Bereichen, nicht gleichzeitig aber doch fast täglich zu unterschiedlichsten Zeiten.
Nein, um 21:00 ist Produktionsende, also spät. 21:15 ist kein MA mehr in der Halle und Licht aus.
Ich kriege diese Reboots auch Nachts um 1, oder an Sonntagen. Also ein Zusammenhang mit einem Schaltvorgang in anderen Stromkreisen lässt sich da nicht erkennen.
Hallo zusammen,
mal ein kleines Update zur Problematik.
Das Ticket beim Support führt nur so mäßig zum Erfolg. Immerhin wird es bearbeitet und hoffentlich auch gelöst.
Anbei mal ein Screenshot zu den Laufzeiten der Shellys:Screenshot 2022-01-06 062334.jpg
Ich habe mehrere, die exakt zur gleichen Uhrzeit neustarten (letzte Zeile). Immer so gruppenweise. Die Shellys sind räumlich nah beieinander, aber alle an unterschiedlichen Steckdosen und Sicherungen. WLAN kann es nicht sein, ich hatte jetzt einige, die aufgrund von Arbeiten am Netzwerk über mehrere Tage offline waren, die sind nicht neugestartet.
Fremdeinwirkung kann auch ausschließen, da um diese Uhrzeit schon ca. 1h Feierabend für alle war.
So wie es jetzt aussieht, war es wohl eine ziemliche Fehlinvestition in diese Geräte. 
Hallo liebe Forengemeinde,
ich bin neu dabei und habe direkt ein Problem mit dem Shelly Plug.
Wir nutzen ca.20 Stück davon bei uns in der Firma um die Stromverbräuche zu messen.
Aktuell sind sie an all unseren Druckern installiert. Die Energiemessung dieser Geräte hat Zoll/Steuerrechtliche Hintergründe, also bitte nicht über Sinn oder Unsinn diskutieren.
Deswegen auch die Entscheidung für den Shelly Plug, da man den einfach installieren kann, ohne in die Tiefen der Gebäudeinstallation einzutauchen.
Es gibt ja genug Geräte, die auch genauer messen können, ist für uns aber nicht so relevant.
Alle Geräte sind im WLAN eingebunden, haben keinen Cloudzugriff und einen internen Zeitserver zugewiesen bekommen. Wir nutzen sie auch nicht zum Schalten, sondern rein zur Messung.
Ach ja, Firmware ist aktuell, Version 20211109-130708/v1.11.7-g682a0db
Soweit funktioniert alles prima.
Jetzt haben allerdings kurz nach der Installation 3-5 Geräte angefangen, sich regelmäßig neuzustarten. Nach jedem Neustart ist natürlich unser Gesamtmesswert weg, da keine Cloud. Ein Abschalten des Schaltrelais konnten wir nicht feststellen.
Wir haben gesucht und überlegt, ob es an einem bestimmten WLAN-AP hängen könnte, da sich alle Geräte in der selben "Ecke" befinden. Evtl. auch Probleme mit der Gebäudeunterverteilung, eben wegen der räumlichen Nähe. Weitergekommen sind wir aber nicht.
Seit ein paar Tagen fangen dieses Verhalten immer mehr von den Geräten an. Unser ITler ist auch ziemlich am Ende mit seinen Ideen...
Der Grundgedanke war, die Messwerte über API_REST in Excel zu importieren. Klappt auch bestens, nur können wir diese Datenabrufe ja nicht minütlich machen, um halbwegs brauchbare Daten zu kriegen.
Kennt jemand das Problem und kann helfen? Welche Möglichkeiten hätten wir noch, um die Daten aufzunehmen?