I have a new WEM3080 which I am testing.

The device has been initialised and connected to my Wifi.

During the device setup I provides my Wifi SSID and key, set the Run Mode to "HTTP" and did not provide a HTTP Address. My DHCP server has a static IP address allocated for the device. I am able to access the device setup page via it's allocated IP address.

I am using the Home Assistant integration to collect data from the WEM3080 device.

However, on 4 occasions over the 2 days I have been testing, the WEM3080 entities are all shown as "unavailable" in Home Assistant, the device cannot be access from a web browser, and a ping to the allocated static IP address fails.

The WEM3080 is located about 2 metres from a Wifi access point, with an internal wall between them, but other devices have shown an RSSI > 80 at that same location. Another WIfi access point with the same SSID is about 30 metres away, with 6 walls between it and the WEM3080.

A check of the DHCP server does not show a different IP address being allocated to the WEM3080 MAC address.

My internet modem provides a status on all devices connected to it, and it shoes the WEM3080 MAC address as "inactive".

All other devices on the Wifi network appear to be operating normally.

However, the red "Wifi" LED on the WEB3080 is illuminated.

Any suggestions on a solution or further diagnostics please?

Hi:

Thanks for your feedback, please give us your firmware version.

http://ip/system.html

some old versions(before 1.75.40) may occur such problems (wifi still connected but http server down).

If so , please upgrade the firmware to the latest version https://imeter.club/topic/11

If the firmware is already the latest version, please also let me know.

 
We will consider adding a stand-alone mode in the future version which is used to respond to local API only.

Thank you "laoliu"

I have updated the firmware from "ATV1.75.32@MX1290" to "ATV2.75.66@MX1290" and will test for a few days then advise the results.

After upgrading the firmware, the WEM3080 has continued to drop off the wireless network. It has dropped off 4 times in the last day after staying connected each time for between 30 minutes and 3 hours. Each time it has dropped off, a power cycle was done of the WEM3080 to force a reconnect.

I have tried changing the Run Mode to "Cloud" and then confirmed that data was being reported by the IamMeter monitoring system. When the WEM3080 drops off the network, that reporting fails too, as you would expect.

Hi:

Please let me know when it " drop off the wireless network" , whether
1 the ssid of iMeter_sn appear around you？
2 the wifi led on front panel is still on?

When your select the mode of "cloud" ,if this problem still exits?

Hello laoliu,

1 the ssid of iMeter_sn appear around you?

No. I have checked with 2 devices and not found the initialisation SSID

2 the wifi led on front panel is still on?

Yes. The red "WIFI" LED is on solid.

The green "RUN" LED is also on, and flickers every 5 to 10 seconds.

When your select the mode of "cloud" ,if this problem still exits?

Yes. I have set the WEM3080 to a Run Mode of "Cloud", and it does still disconnect.

I also noticed that if I left the WEM3080 powered on after it had disconnected, on 2 occasions after a few hours if has reconnected to the network, before later dropping off again.

My plan is to try doing a factory reset and setting up the WEM3080 with just the cloud connection and no Home Assistant integration to see what happens. I don't believe it should make a difference. but need to try al options.

Hi,

Thanks for your feedback.

It is a little strange.

"The green "RUN" LED is also on, and flickers every 5 to 10 seconds."    This means the wifi firmware is work properly (request data every 6 seconds) 

Yes. The red "WIFI" LED is on solid. This means the device has still connected to the router(wifi connection). but the HTTP get fails. 

This problem is probably due to the process of IP allocation.

I notice that you said the device had been allocated a fixed ip.
Please tell me whether you allocated the static ip by IAMMETER app setting ,or allocated the static ip from the router function?

if you set the static ip by IAMMETER-app, please try to change it back to dynamic ip and check whether this problem will still exist.

I had a similar problem. 

Maybe it's the same for you. The cable to the antenna socket was not soldered, only covered with insulation. As a result, the antenna did not come into contact with the meter and the wifi range was very poor.

 :) such a producer error.

Hi Maciej:

Thanks for your feedback, if possible, please give us a detailed picture to illustrate your problem. (You can post it in a new thread)
The antenna socket is buckled in the wifi module on PCB, not solder. And if the wifi module has poor signal strength because of the antenna socket installation(not buckled well), the meter will not pass the aging process before leaving the factory. And there are indeed few customers to contact us for feedback about the problem of wifi strength. So we also want to know what is your problem.

For the problem of David, it is not caused by the wifi strength.
If it is introduced by the low wifi strength, the wifi led should be off and the corresponding SSID(iMeter_sn) would appear.

Thanks Maciej for the suggestion, but the WEM3080 is only 2 metres from the wireless access point and shows a strong signal strength of "-49" (I assume dbm). An antenna connection issue would make no effective difference.

Laoliu, the IP address for the WEM3080 is pre-allocated at my DHCP server. There should be no IP conflict, but as a test I have deleted the pre-allocated address at the DHCP server so that the WEM3080 IP comes from the DHCP pool.

Hi:

we have also tested it in your previous situation from Monday. (mode:http, empty url), the problem has not appeared yet.

So I think this (http & empty url) may not the key of the problem.

The main problem is still why the products can not be visited when the wifi LED is on.

We had met this problem before, it has two possibilities.
1 wifi led is on , ping ok, but http get fails
This problem is caused by the bug in firmware before 1.75.4, you can upgrade the firmware to solve this issue.
2 wifi led is on, pink fails.
This problem is caused by the IP, the products usually are allocated in static ip in this case.
In this problem, the wifi connection is still OK, but the IP is not visitable at some time.
we have not confirmed whether this problem is introduced by device firmware or the corresponding router. But change the IP allocation to DHCP will solve this problem.

Thank you laoliu

In my case the wifi LED is on, but the device does not respond to pings at it's allocated IP address.

It has been getting that IP address from my DHCP server, and it was an allocated address, which should have no conflicts.

I will continue to monitor how the WEM3080 behaves, and report any results here.

Thanks again.

It is my pleasure.

Please let me know if there is further information.

laoliu,

Some further feedback.

I believe I have isolated the WEM3080T network dropout to being dependent on the upload interval.

With the WEM3080T device set to "Cloud" mode, with no other system accessing the device, it will run reliably.

If I leave it in "Cloud" mode and add IamMeter integration to Home Assistant, it will then fail as reported previously.

If I set the WEM3080T to TCP mode, connecting to my MQTT broker, and without any Home Assistant integration, it will also fail.

However, if I leave it in TCP mode and change the "upload interval" from the default value of 1, ie every 6 seconds, to a value of 10, with no other changes to the device or my network, it will then remain connected and report reliably.

For me, obtaining data every 60 seconds (upload interval = 10) via MQTT is sufficient, so I can now use the WEM3080T device.

However, I am providing feedback in case it is useful for other users, or for your ongoing development work.

Thank you for your support.

Thanks.

Your feedback is valuable, I will forward this to my colleague.

Thanks again.

Sorry I also need to confirm more details.

If I leave it in "Cloud" mode and add IamMeter integration to Home Assistant, it will then fail as reported previously.

Whether this problem is still as your description before?
Ping fails, wifi led is on, not recover automatically.

Because the "cloud" + HA is the basic working mode and had been supported for a long time, so I need to confirm more details about this problem.

If I set the WEM3080T to TCP mode, connecting to my MQTT broker, and without any Home Assistant integration, it will also fail.

If it means you upload via MQTT every 6 seconds? 

And the fail also means "Ping fails, wifi led is on, not recover automatically"?

Thanks

Following: I am getting the same issues as David but not as often. I think it has only happened 2 or 3 times in the last month since I installed. I have a ping sensor set up to alert me when it happens. Seems the only thing to do is to reboot the device.

I haven't tried making any config changes to get around it.

Hi:

please help us to confirm your specific situation.

1 dhcp or static IP ?

2 cloud or tcp->mqtt ?

3 if the mode is tcp->mqtt, what is the upload interval?

4 whether you use Home Assistant?

Sorry I forget one question
5  what is the longest faulty time before your manual intervention (the longest stop uploading time before you handle it manually)?

Because there is auto-reboot logic in the firmware, it will reboot every 24 hours.

I wonder whether the product can resume from faulty within 24 hours.

Hello laoliu,

If I leave it in "Cloud" mode and add IamMeter integration to Home Assistant, it will then fail as reported previously.

Yes, same symptoms as I reported previously. Pings fails, Wifi led is still on.

I have not seen an automatic recovery. However, based on your description of a 24 hour timeout or reboot, I would not have waited that long before restarting the device myself.

Yes, this is uploading via MQTT using the default upload interval, which I believe is 6 seconds.

The symptoms are the same as when issue occurs in "cloud" mode.

I have now had the WEM3080T running reliably for a week in TCP/MQTT mode with upload interval = 5, ie 30 seconds.

As an experiment, I will try setting it back to upload interval = 1, ie 6 seconds, and see what happens.

laoliu

Sorry I also need to confirm more details.If I leave it in "Cloud" mode and add IamMeter integration to Home Assistant, it will then fail as reported previously.Whether this problem is still as your description before?Ping fails, wifi led is on, not recover automatically.Because the "cloud" + HA is the basic working mode and had been supported for a long time, so I need to confirm more details about this problem.If I set the WEM3080T to TCP mode, connecting to my MQTT broker, and without any Hom

One other aspect of my setup which is probably not typical, is that I have 3 wireless access points within range of the WEM3080T, with varying signal strengths. Those access points all have the same ESSID.

I wondered whether the EM3080T may periodically try to reconnect to wifi, potentially choose a weak access point, and hence drop off the network when that attempt fails?

I think this may the key of this problem.
we will try to test this case recently(whether ap switch affect the reliability of connection)
Because the wifi led is always on, this is a typical symptom that the wifi connection is still on but IP-allocation has some problems.
I do not consider the ap switching will cause such problem, but we will test in such case and report the result here.

Hi, we have just checked the code and find the auto-reboot interval is 10hours now(not 24hours I mentioned above).

Please let me know, have you ever found a halt time of more than10 hours before? (before your manual intervention).

we have done such a test in our lab today.

Use two APs with the same ESSID around the device.
Connect the device into one AP, then power down the connected ap. we found the device can be switched to another AP quickly(within 60 seconds). we do the same test many times, and the result is also the same.

The result of our test:
the ping will fail during the switching process of the AP but it will recover soon.

Consider the phenomenon of your description, it seems the device is always connected to a AP, but the IP level has some problems after some time(ping fail).

I was also curious about what causes this problem.

If possible, please do not reboot it manually when it occurs such a problem next time.
we will know whether it will return to work within 10hours(the maximum reboot cycle is 10hours). Then it will tell us whether the firmware is still running correctly at that time. (the auto-reboot function is controlled by the firmware, not hardware)

Hello laoliu,

I think I have removed AP switching as a potential cause of this issue.

For the last few days my WEM3080T has been setup to connect to an AP with a unique ESSID. There are other APs within range, but only one AP has the ESSID to which the WEM3080T is configured to connect. The WEM3080T "upload interval" has been 5, and it has been reporting reliably

This morning I changed the upload interval to 0 (= 6 seconds), and confirmed this by subscribing to the MQTT "device/<serial number>/realtime" topic and observing that a message was received about every 6 seconds. I made no other WEM3080T or network changes. About 15 minutes after changing the upload interval to 0, the WEM3080T stopped reporting and it does not respond to pings. As previously, the red wifi led is on, and the green "run" led is on and is flashing off periodically.

So a change just in the upload interval appears to have triggered a disconnect failure.

I will leave the WEM3080T in that state for at least 10 hours and see if there is any change, then report results here.

laoliu

Hi, we have just checked the code and find the auto-reboot interval is 10hours now(not 24hours I mentioned above).Please let me know, have you ever found a halt time of more than10 hours before? (before your manual intervention).we have done such a test in our lab today.Use two APs with the same ESSID around the device.Connect the device into one AP, then power down the connected ap. we found the device can be switched to another AP quickly(within 60 seconds). we do the same test many times, and

Thanks for your feedback, looking forward to your further information.

Hello laoliu,
Here is a log of changes in the status of the WEM3080T.
Other than the initial upload interval change there have been no other changes or interactions with the WEM3080T. Prior to the upload interval change the WEM3080T had been running reliably for a few days.

28 Sept
10:15 - Upload interval param changed from 5 to 0
10:33 - Last MQTT message before updates stop and device is unresponsive to pings
15:13 - MQTT messages start again
17:36 - Last MQTT message before updates stop and device is unresponsive to ping (ran for 02:23)

29 Sept
00:58 - MQTT messages start again (07:22 since stop, 11:45 since last start)
01:28 - Last MQTT message before updates stop (ran for 00:30)
07:55 - MQTT messages start again (06:27 since stop, 06:57 since last start)
11:14 - Last MQTT message before updates stop (ran for 03:19)

Hi, thanks for your information, from your feedback
1 the auto-reboot function seems ok, it means the firmware is still running.
2 the problem will have occurred easily when you set the upload interval to 0(upload every 6 seconds). It even can not last an hour and will last a long time until the auto-reboot recovery code had been executed.
This is very strange from my side because there are more than 10 pcs products that are always in test in our lab. They are all uploading in the minimum interval by MQTT. But no product in testing met such a problem.
We have not added such testing products in HA, but we also request the local API for each 10seconds which means it requests the local data more frequently than HA.

Maybe the only difference is we do not introduce the continuous ping operation in the testing, I will let my testing colleague add such operation and check the result.

By the way, we found a memory leak problem in our latest version.
It will happen if you use the MQTT uploading mode.
This bug will lead the product would be rebooted every several hours(the specific reboot interval depends on the upload interval), but the upload will only be affected 1-2 mins by this exception reboot.
So I think your problem has nothing to do with this bug.

We will release a new firmware to solve this memory leakage bug in near future.

we will feedback here if we have any new testing results.

Thanks for your feedback again.

Thanks for your response laoliu.

For my purposes, MQTT uploads and an upload interval value of 4 or 5 is sufficient, and with those settings the WEM3080T has proven reliable.

So this issue I have experienced is not a show stopper for me.

I will now install the WEM3080T in a switchboard and set it to work.

laoliu

Hi, thanks for your information, from your feedback1 the auto-reboot function seems ok, it means the firmware is still running.2 the problem will have occurred easily when you set the upload interval to 0(upload every 6 seconds). It even can not last an hour and will last a long time until the auto-reboot recovery code had been executed.This is very strange from my side because there are more than 10 pcs products that are always in test in our lab. They are all uploading in the minimum interval

Probably I have the same issue.

Each 35160 seconds(586 minutes) home assistant loses data from iammeter(I have a template sensor because iammeter doesn't allow to set initial import energy value):

timestamps:

- 15:23:02

- 01:09:02

- 10:55:02

I updated the firmware to the latest version:

It seems like the iammeter reboots at these timepoints, because it's rebooted ~47 min ago:

and ~20 minutes after that resets wifi connection:

I'm using DHCP server and set a static ip for the dhcp client(iammeter).

Hi:

"Each 35160 seconds(586 minutes) home assistant loses data from iammeter(I have a template sensor because iammeter doesn't allow to set initial import energy value)"

Yes, there is an auto-reboot cycle in the firmware which is around10 hours(586 mins) in the latest version.

It seems like the iammeter reboots at these timepoints, because it's rebooted ~47 min ago:

Your analysis is correct.

and ~20 minutes after that resets wifi connection:

Please check whether there is data lost after the device reboot (from the 47 mins ago to the 28 mins ago)?

> Please check whether there is data lost after the device reboot (from the 47 mins ago to the 28 mins ago)?

In home assistant it looks like this(the gap is 30 seconds) -

laoliu

Hi:"Each 35160 seconds(586 minutes) home assistant loses data from iammeter(I have a template sensor because iammeter doesn't allow to set initial import energy value)"Yes, there is an auto-reboot cycle in the firmware which is around10 hours(586 mins) in the latest version.It seems like the iammeter reboots at these timepoints, because it's rebooted ~47 min ago:Your analysis is correct.and ~20 minutes after that resets wifi connection:Please check whether there is data lost after the device reb

> Yes, there is an auto-reboot cycle in the firmware which is around10 hours(586 mins) in the latest version.

Is it a correct/normal behavior? It reboots even when everything is ok?

Hi, from your pic, it seems ok.
This is not ought to be the problem that David met before.
The auto-reboot logic is mainly for some unexpected exceptions.
Because the startup time of this device is short, so it will not affect anything in most cases.
Could you please tell me how frequently you request the data in HA?
I remember the default time is 1min.
We recommend using a periodic sample interval greater than 30 seconds.

Hi.

But the docs say there is no such parameter - https://www.home-assistant.io/integrations/iammeter/ so I haven't set in to 30 secs nor 1 min, it's a default value set somewhere.

laoliu

Hi, from your pic, it seems ok.This is not ought to be the problem that David met before.The auto-reboot logic is mainly for some unexpected exceptions.Because the startup time of this device is short, so it will not affect anything in most cases.Could you please tell me how frequently you request the data in HA?I remember the default time is 1min.We recommend using a periodic sample interval greater than 30 seconds.

I am having this issue now. I am using node-red to query the device using the iammeter node. (https://flows.nodered.org/node/node-red-contrib-iammeter)

I have a reservation in my DHCP to set the static ipaddress of 192.168.8.248, and on the latest firmware of ATVi.75.98.66@MX1290.

If i query the device every 6 seconds, it will lose connection just like mentioned before. WIFI led is on steady red, green led blinks every few seconds. Cant ping the device nor get to the web page of the device. Sometimes it will stay connected for an hour or 2 other times it will only stay connected a few minutes. 

If i change the query time to longer, say 10 seconds or 30 seconds, it will stay connected for longer possibly lasting more than the 10 hour reboot interval. However I would like to query the device as often as possible, such as every second or 2.

I have noticed a couple of ways to reconnect the device once it disconnects. One is to reboot the device, but this is not a suitable solution for me, and two is to restart the DHCP services on my DHCP server. This one I find strange, however is not a suitable solution either. 

I dont feel there is anything misconfigured in my DHCP because all of my other devices (pc's, IoT devices, cell phones, etc) have no issues with getting dynamic or static (reserved) ipaddresses from my DHCP. 

I am willing to help troubleshoot this issue and provide you with any information needed.

Please let me know,

1 Have you used the mesh AP in your WLAN? if so, what is the AP brand and model?

2 how do you operate the DHCP restart? If possible, please give me a snapshot.

We indeed met one issue like this in one of our customers before.
In some mesh AP WLAN( with specific router brand), the meter seems to be halted by the DHCP packet send by DHCP server and resumed by the next packet.
The customer once help us sniff the packet so we found this issue is with regard to the DHCP, but because we can not find the same router and AP around, we can not reproduce this problem in our lab.

So please let me know the brand of your router and AP.
We will check whether they are the same model as the previous customer having the same issue.

The AP is a ubiquiti UAP-LR that is is currently connected to and it is in a mesh environment.

The DHCP restart is just a typical windows DHCP Server services restart. I have a windows 2022 datacenter as my DHCP. 

It did get disconnected sometime earlier today, with a 10 second query. 

laoliu

Please let me know,1 Have you used the mesh AP in your WLAN? if so, what is the AP brand and model?2 how do you operate the DHCP restart? If possible, please give me a snapshot.We indeed met one issue like this in one of our customers before.In some mesh AP WLAN( with specific router brand), the meter seems to be halted by the DHCP packet send by DHCP server and resumed by the next packet.The customer once help us sniff the packet so we found this issue is with regard to the DHCP, but because we

the router that i am using is a ubiquiti dream machine se

Hi:

Thanks for your detailed replies ,there are some further questions 

1 .how do you find the relationship between the restart of the DHCP server and the device stop and resume?

In other words, what makes you try to restart the DHCP server and find it can resume the device?

2 Have you tried to fix an IP like this https://imeter.club/topic/173 and whether the problem still exist?

3 Have you tried to use the DHCP server that the router provided (not the windows 2022 datacenter ), and whether the problem still exists?

4 the topic is posted a long time ago , at that time,the TCP/Modbus was still not supported.

Honest speaking , it is not a good option to request data very fast by HTTP get.

You can also try to use the modbus/tcp and check whether it would resolve this problem 

https://www.iammeter.com/newsshow/news-modbus-tcp-energy-meter

So I just stumbled on the restart of the DHCP services by accident. but when i restart the DHCP service the device reconnects immediately.

I havnt used the built in DHCP in my router because I have had the windows ones for years, and the router is relatively new.  (Within 1 year)

I would set the ipaddress manually in the device, but I have never been able to get the app on my phone (IPhone) to connect. when I try and put in the ip address (192.168.8.248) into the app, it says invalid network. it has never worked since the device was new.

The device was working fine for years, this issue just started in the last month or so. and as far as I know nothing has changed in my network in that time.

I purchased the device in July 2021. and most things have worked without issue until now. 

the app has never been able to connect.

Modbus/tcp can connect after the device reconnects.

laoliu

Hi:Thanks for your detailed replies ,there are some further questions 1 .how do you find the relationship between the restart of the DHCP server and the device stop and resume?In other words, what makes you try to restart the DHCP server and find it can resume the device?2 Have you tried to fix an IP like this https://imeter.club/topic/173 and whether the problem still exist?3 Have you tried to use the DHCP server that the router provided (not the windows 2022 datacenter ),

I found an android device and have set the IP manually, with the android app.

will test for a while and see if it works.

"The device was working fine for years, this issue just started in the last month or so. and as far as I know nothing has changed in my network in that time."

This is so strange, I once thought this problem exists since the first day.
Are there any other changes at the time point when this problem occurs?
Have you upgraded the firmware? or whether the windows 2022 data center upgrade ?

windows could have updated, it is set to automatic. 

I set the static ip in the device, and it is still working. for 14 hours so far. 

but it is strange that it is the only device that drops connection like that.

Yes, so I hope to find out the all possible difference.

The key is the first time when this problem occurs.
what brings the difference before and after that time point.

I dont have any idea what caused it to break, but setting the static IP in the device solve this issue. 

Thanks for your help!

laoliu

Yes, so I hope to find out the all possible difference.The key is the first time when this problem occurs.what brings the difference before and after that time point.