ProEM50 eth (lan) connection problem.

[shacca.pl]

Hello, I have a problem with the eth (lan) connection.  It only worked for a few minutes.   Router, cable, LAN surge protection - everything works.  The LAN port on the meter has stopped working.  Firmware up to date.  In the application and via the web panel, the ethernet is shown as disconnected.  I wanted a device with a stable cable connection.  Maybe someone had a similar case and has a solution?

[Heinz]

i have not seen this type of issue could you provide a ping test to the device and maybe the device logs maybe something we can see from there

[shacca.pl]

This is a bit strange. After connecting the network cable to Shelly and to the switch, there is no connection. The indicator on the switch and Shelly does not light up, it looks like there is no physical connection. Cables, switch, plugs, everything checked, functional. I left the devices connected like this and after a few hours suddenly the connection appeared out of nowhere. Shelly pro em 50 connected, got the IP address from dhcp, ping goes through, so it works. However, the behavior is a bit strange, I already thought the device was faulty. I don't know why this happened, maybe someone had a similar experience?

[elfun]

Hi, I'm not sure if it's the same issue, but I'm already experiencing interruptions in data retrieval. The Shelly device is connected via both cable and Wi-Fi. When I stop receiving data, I can't access it through the web page, either via the cable connection's IP or the Wi-Fi connection's IP. However, I can ping both IPs, and when I scan the ports of the IPs, it shows that port 80 is open. I also can't access it through the app. The only solution is to reset the device or wait for the connection to restore itself. The version is

[thgoebel]

1 minute ago, elfun said:

The Shelly device is connected via both cable and Wi-Fi.

This was not intended by the inventor and may lead to serious network trouble!

Edited December 12, 2024 by thgoebel

[elfun]

Initially, it was connected ONLY via cable, and I was experiencing the same issues. I tried using both cable and Wi-Fi to see if there was any different result...

[elfun]

Hi, just in case it's useful, I've been performing a software reset every day for the past five days, and I haven't had any connection issues.

[Heinz]

thanks for the update. Could have been a small bug or setting within the app. 

[elfun]

Hi, I don’t think so. The problem reoccurs if I stop performing the daily reset. The issue is that it usually fails if it’s not restarted within a period of two or three days. I haven’t been able to determine the exact failure period since it happens after several days.

[Heinz]

this is not normal. 

what i would maybe look into is the network connection. How are you connecting the device to the network? 

Lan cable type?
cable length ? 
what type of router 

can you provide a screen shot of the device when you ping it with windows machine. 

open CMD and type this command 

ping 192.168.0.15 -t 

can you enable the logs on the device and post them here as well 

[elfun]

Hi, sorry for the delay in responding.

Yesterday, 1/12/25, the issue occurred again (the device had been working without problems with the daily reboot). I was able to ping and access the web page, but after waiting a couple of minutes, the page would load. However, it was impossible to navigate properly, as I couldn’t access the device’s data. A hardware reset was necessary.

The device is connected using a CAT-6 cable approximately 11 meters long to a router. This router, in turn, is connected to the local network using another CAT-6 cable about 23 meters long. All the devices connected to this router are functioning correctly.

This morning, I noticed that a new firmware version is available, and I’ve updated to 1.5.0-beta1. From now on, I will run tests using this version.

I obtain the data from a smart home device through HTTP requests and also from Home Assistant, using the integration: https://www.home-assistant.io/integrations/shelly. The data I am sharing below is current with the 1.5.0-beta1 version.

Ping result

PING 192.168.0.15 (192.168.0.15) 56(84) bytes of data.
64 bytes from 192.168.0.15: icmp_seq=1 ttl=255 time=0.948 ms
64 bytes from 192.168.0.15: icmp_seq=2 ttl=255 time=0.529 ms
64 bytes from 192.168.0.15: icmp_seq=3 ttl=255 time=0.618 ms
64 bytes from 192.168.0.15: icmp_seq=4 ttl=255 time=0.649 ms
64 bytes from 192.168.0.15: icmp_seq=5 ttl=255 time=0.579 ms
64 bytes from 192.168.0.15: icmp_seq=6 ttl=255 time=0.741 ms
64 bytes from 192.168.0.15: icmp_seq=7 ttl=255 time=0.518 ms
64 bytes from 192.168.0.15: icmp_seq=8 ttl=255 time=0.496 ms
64 bytes from 192.168.0.15: icmp_seq=9 ttl=255 time=0.524 ms
64 bytes from 192.168.0.15: icmp_seq=10 ttl=255 time=0.572 ms
64 bytes from 192.168.0.15: icmp_seq=11 ttl=255 time=0.640 ms
64 bytes from 192.168.0.15: icmp_seq=12 ttl=255 time=0.616 ms
64 bytes from 192.168.0.15: icmp_seq=13 ttl=255 time=0.538 ms
64 bytes from 192.168.0.15: icmp_seq=14 ttl=255 time=0.657 ms
64 bytes from 192.168.0.15: icmp_seq=15 ttl=255 time=0.581 ms
64 bytes from 192.168.0.15: icmp_seq=16 ttl=255 time=0.594 ms
64 bytes from 192.168.0.15: icmp_seq=17 ttl=255 time=0.652 ms
64 bytes from 192.168.0.15: icmp_seq=18 ttl=255 time=0.722 ms
64 bytes from 192.168.0.15: icmp_seq=19 ttl=255 time=0.656 ms
64 bytes from 192.168.0.15: icmp_seq=20 ttl=255 time=0.581 ms
64 bytes from 192.168.0.15: icmp_seq=21 ttl=255 time=0.565 ms
64 bytes from 192.168.0.15: icmp_seq=22 ttl=255 time=0.699 ms
64 bytes from 192.168.0.15: icmp_seq=23 ttl=255 time=9.21 ms
64 bytes from 192.168.0.15: icmp_seq=24 ttl=255 time=7.85 ms
64 bytes from 192.168.0.15: icmp_seq=25 ttl=255 time=5.99 ms
64 bytes from 192.168.0.15: icmp_seq=26 ttl=255 time=4.99 ms
64 bytes from 192.168.0.15: icmp_seq=27 ttl=255 time=3.99 ms
64 bytes from 192.168.0.15: icmp_seq=28 ttl=255 time=3.17 ms
64 bytes from 192.168.0.15: icmp_seq=29 ttl=255 time=2.40 ms
64 bytes from 192.168.0.15: icmp_seq=30 ttl=255 time=20.2 ms
64 bytes from 192.168.0.15: icmp_seq=31 ttl=255 time=279 ms
64 bytes from 192.168.0.15: icmp_seq=32 ttl=255 time=0.677 ms
64 bytes from 192.168.0.15: icmp_seq=33 ttl=255 time=0.720 ms
64 bytes from 192.168.0.15: icmp_seq=34 ttl=255 time=0.703 ms
64 bytes from 192.168.0.15: icmp_seq=35 ttl=255 time=0.626 ms
64 bytes from 192.168.0.15: icmp_seq=36 ttl=255 time=0.508 ms
64 bytes from 192.168.0.15: icmp_seq=37 ttl=255 time=0.677 ms
64 bytes from 192.168.0.15: icmp_seq=38 ttl=255 time=0.677 ms
64 bytes from 192.168.0.15: icmp_seq=39 ttl=255 time=0.691 ms
64 bytes from 192.168.0.15: icmp_seq=40 ttl=255 time=0.667 ms
64 bytes from 192.168.0.15: icmp_seq=41 ttl=255 time=0.727 ms
64 bytes from 192.168.0.15: icmp_seq=42 ttl=255 time=0.692 ms
64 bytes from 192.168.0.15: icmp_seq=43 ttl=255 time=0.701 ms
64 bytes from 192.168.0.15: icmp_seq=44 ttl=255 time=0.667 ms
64 bytes from 192.168.0.15: icmp_seq=45 ttl=255 time=0.652 ms
^C
--- 192.168.0.15 ping statistics ---
45 packets transmitted, 45 received, 0% packet loss, time 44835ms
rtt min/avg/max/mdev = 0.496/7.996/278.908/40.981 ms

 (24h) Monitor HTTPs, URL http://192.168.0.15/#/

diagnostics-shelly-proem-debug-log.txt

Edited January 13 by elfun

[Heinz]

have the cables been tested and just to make sure as you are connecting two routers together you don't have a loop in the network. 

this is a strange issue 

[elfun]

Yes, if I use the same cable with another device, there’s no problem, and if I use the Wi-Fi connection, the issue is NOT resolved. However, with the beta version, I haven’t had any issues so far... we’ll see in a few days. Thank you for your help!

[Heinz]

Ok cool seems I was starting to really wonder what the issue could have been. 
If you could update in a week or so then that should be a good test to know if the issue is solved with the firmware update 

[elfun]

Hi Heinz,

Since I started using the beta version (1.5.0-beta1), I haven’t encountered any problems. I also haven’t performed any resets on the device. However, I do feel that the update of readings is somewhat slower compared to version 1.4.4. This is just an observation; I can’t be certain, but the current performance is satisfactory.

[Heinz]

Awsome thanks for providing the update

[Abbe]

Hello everyone,

 

For information, I experimented the same issue in the version 1.5.1.

I just updated my device to 1.6.0 Beta 2. I will try that and give my retrun as soon as I know th result !

[Abbe]

Hello guys !

I am still experimenting the issue of unreachability to the device. I tried some tests that I will expose to you. I hope that can help.

Test HTTP connexion to the shelly:

15h07 -> OK

15h18 -> OK

16h11 -> OK

I disconnected my computer to the network, connect to another and go back (30s of being disconnected) -> the problem appeared !

When the problem come, I can't access to the device both http and modbus request.

When I launch Network analyzer (phone tool to scan the network), he wake up quickly.

[Abbe]

Hello guys ! 

I tried to switch from WIFI to ETH (before, I was only in WIFI) and I disabled the WIFI.

Since I did that, I don't see any problems. So this probably solved my problem.