hello mircho,
so the log is from the ioBroker adapter, which communicates via MQTT.
There are definitely reboots, I monitored that with a webcam. Using the log entries, I could always filter out the times and see on the display that Shelly is rebooting!
Another user has also reported this behaviour here: https://github.com/iobroker-commu…ment-1061716665
Cheers
hello everyone,
i have been using 0.10.0-beta6 since saturday. since then there have been no more freezes!
But what I have noticed is that the shelly reboots at regular intervals (see Log at the end). I watched it via webcam and it does reboot.
In summary, it seems that this (or another) problem still exists, but the shelly now reacts with a reboot instead of a freeze.
This is definitely a "step forward", as the device is still accessible and if the reboot does not happen with a switching operation, it is not "noticeable".
Daniel
shelly.0 2022-03-07 09:24:26.355 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 08:57:41.610 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 08:56:28.094 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 08:37:22.622 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 08:31:48.834 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 08:28:01.803 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 08:18:38.274 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 08:13:19.744 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 07:52:11.708 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
shelly.0 2022-03-07 07:45:52.004 info [MQTT] Device 192.168.41.161 (shellypro4pm / shellypro4pm-083af27d164c / shellypro4pm#083af27d164c#1) connected! Polltime set to 15 sec.
hello mircho,
unfortunately I have not noticed any change with 0.10.0-beta5.
cheers
daniel
Hello everyone,
Our automated tests did help us localize the problem to be correlated to Ethernet and not really to communication over it. We would like to offer to you custom firmware for Pro 4PM that has Ethernet entirely disabled.
hello mircho,
is this update only for those who hast the problem also with WLAN?
hi,
here's some quick feedback:
I was able to install the firmware today (display was deactivated as described, also the operating buttons were inactive).
Then I switched back to LAN.
Unfortunately, it didn't take 10 minutes before the Shelly crashed again.
After a short power off/power on it worked again for 10 minutes, then it crashed again.
I have now switched back to WiFi...
Hi, I don't think I can do this so easily 
I have tried to send the curl command via the windows console, unfortunately without success.
Could someone please provide more detailed instructions for dummies.
Sorry for that
Would you be willing to install a custom firmware version that has the display fully disabled. We would like to eliminate factors that can be causing the failure. Drawing on the display is being done in another thread, but still consumes cycles and can lead to conditions where specific communication and device update can be a cause for failure. So far we have not been able to reproduce it ourselves.
hi,
If I can help here too, I'll be happy to join in.
But I don't have a cloud connection for the shelly!
Just let me know if you want to test something...
Hi, I am currently switching exactly one relay with a very small load.
I switch such a contactor: https://datasheet.eaton.com/datasheet.php?…86&locale=de_DE
The shelly measures approx. 1,2W
Hope this helps...
hello mircho, thanks for the feedback.
perhaps the following insight is also interesting.
at the beginning, i had not stored an authentication password. i had no reason for this. via LAN connection, the error occurred after a few minutes to an hour.
I set this password yesterday. since then, the shelly via LAN has survived for about a day until the error occurs.
I don't know if this contributes to solve the problem.
Otherwise, thank you for looking into the matter!
Greetings
Good morning everyone,
It's hard for me to imagine that it's the eth-config.
I rather suspect a problem in the communication via MQTT.
In another test, I operated the Shelly with LAN and only deactivated the MQTT server, in my case ioBroker (MQTT config in the Shelly was still activated!). Here the Shelly also ran without problems.
Only when communicating via MQTT again, the error showed up again!
Daniel
Hello Mircho,
this is my config. I see the problem with the freezing Shelly only when it's connected via eth! Over WiFi it's working fine.
Cheers,
Daniel
PS: I have manipulated a few private points, such as passwords or geo-coordinates.
{"ble":{"enable":false},"cloud":{"enable":false,"server":"iot.shelly.cloud:6012/jrpc"},"eth":{"enable":false,"ipv4mode":"static","ip":"192.168.41.161","netmask":"255.255.255.0","gw":"192.168.41.1","nameserver":"192.168.41.1"},"input:0":{"id":0, "name":null, "type":"switch", "invert":false},"input:1":{"id":1, "name":null, "type":"switch", "invert":false},"input:2":{"id":2, "name":null, "type":"switch", "invert":false},"input:3":{"id":3, "name":null, "type":"switch", "invert":false},"mqtt":{"enable":true,"server":"192.168.41.120:1882","user":"mqttuser","pass":"1234","topic_prefix":"shellypro4pm-94b97ec06adc","rpc_ntf":true,"status_ntf":false},"switch:0":{"id":0, "name":null,"in_mode":"follow","initial_state":"match_input", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00,"power_limit":null,"voltage_limit":280,"current_limit":16.000},"switch:1":{"id":1, "name":null,"in_mode":"follow","initial_state":"match_input", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00,"power_limit":null,"voltage_limit":280,"current_limit":16.000},"switch:2":{"id":2, "name":null,"in_mode":"follow","initial_state":"match_input", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00,"power_limit":null,"voltage_limit":280,"current_limit":16.000},"switch:3":{"id":3, "name":null,"in_mode":"follow","initial_state":"match_input", "auto_on":false, "auto_on_delay":60.00, "auto_off":false, "auto_off_delay": 60.00,"power_limit":null,"voltage_limit":280,"current_limit":16.000},"sys":{"device":{"name":"shelly1","mac":"94B97EC06ADC","fw_id":"20220117-162030/0.9.3-g354c141","eco_mode":false},"location":{"tz":"Europe/Berlin","lat":50.000002,"lon":10.000002},"debug":{"mqtt":{"enable":false},"websocket":{"enable":false},"udp":{"addr":null}},"ui_data":{},"rpc_udp":{"dst_addr":null,"listen_port":null},"sntp":{"server":"192.168.41.1"},"cfg_rev":46},"ui":{"idle_brightness":30},"wifi":{"ap":{"ssid":"ShellyPro4PM-94B97EC06ADC","is_open":true, "enable":false},"sta":{"ssid":"test","is_open":false, "enable":true, "ipv4mode":"static","ip":"192.168.41.162","netmask":"255.255.255.0","gw":"192.168.41.1","nameserver":"192.168.41.1"},"sta1":{"ssid":null,"is_open":true, "enable":false, "ipv4mode":"dhcp","ip":null,"netmask":null,"gw":null,"nameserver":null},"roam":{"rssi_thr":-80,"interval":60}}}Hallo Zusammen,
ich teste den Pro4PM nun auch ein paar Wochen und habe auch das Problem, dass dieser abstürzt, aber nur wenn die Verbindung über LAN erfolgt.
Ich habe das mittlerweile mit Firmware 0.9.1, 0.9.2 und 0.9.3 getestet und immer das gleiche Bild. Nach kurz oder lang "friert" er ein, das Display ist schwarz und nur stromlos machen hilft.
Mit WLAN hatte ich, auch über 2-3 Wochen, dieses Problem nicht.
Ich verwende beim LAN eine statische IP und ich verwende MQTT.
Auch vlt. wichtig, wenn MQTT nicht aktiv ist, bleibt auch die Verbindung über LAN stabil!
VG...