thank you for sharing
Update:
TL;DR: My IoTaWatt is now back connected to my local network using a different access point with its own SSID. My Home Assistant is also being populated with IoTaWatt data. This is just a trial solution for the moment until we resolve what the permanent solution should be.
Some more info:
After one afternoon last week running various diagnostics with remote PC access, Craig did not find anything obviously strange with my network. Other than the IoTaWatt would not connect no matter what we tried.
So it was going to need deeper diagnostics to work out how to get the IoTaWatt connected to my network. Craig lent me a 16 port TP-Link switch, an ASUS router, a Windows laptop, various cables etc for that but it would need to wait for another day as we ran out of time.
Craig also suggested I try a new power supply cable and a different power supply for the IoTaWatt. I did that but with no change to the result, IoTaWatt still not connecting to my network. He just wanted to rule out power supply issues.
So today we got a chance to go again and hooked up the switch and router Craig provided which he then set up to provide separate wireless access point with its own SSID.
Once that was done I was able to successfully connect the IoTaWatt to the ASUS routerâs AP and the IoTaWatt is now connected to my local network network and is also updating my Home Assistant as normal.
So thatâs good news.
The plan now is to monitor how well the IoTaWatt maintains this new network connection over the next week. If it remains solidly connected (despite the low RSSI) then I think we can reasonably say the Telstra âmeshâ local network is the root of all my evils and we can move to the next phase of the plan and replace it with something better.
Itâs not a simple job (for me) as I have some considerations when swapping to a new network, e.g. because our internet is a fixed wireless service which tends to experience regular outages (usually local tower maintenance/upgrades), I wanted a service with 4G mobile data backup. My wife works from home and we need that backup capability.
Telstra is the only ISP here which offers this as standard feature in their router and it is included in the cost of the service. The other major ISP player here has lousy 4G signal where we are.
Craig will make some suggestions on how we set that up.
All up we really canât say what the technical cause of problem is, just that there is a way forward.
Iâll report back the results as the experiment continues.
A great many thanks to Craig for his generosity, support and time to help me out. Honestly there is no way I could navigate these things without such specialist aid.
Iâll have a bit of data cleaning to do as Home Assistant is now showing big negative data values for the IoTaWatt data channels today. I was expecting large energy numbers, just not negative ones!
HA has a pretty rudimentary database editor, so itâs a bit painful.
Hopefully it returns to normal energy readings tomorrow.
Whatever the long term network solution is, Iâll also be wanting to factor in the energy consumption of the devices. For reference the switch and router added ~ 20 W.
Interim update. Logs since we disconnected from the old connection yesterday afternoon and started the new connection with the ASUS router:
5/02/23 15:35:46 Disconnect command received.
5/02/23 15:35:47 WiFi disconnected.
** Restart **
SD initialized.
5/02/23 05:36:51z Real Time Clock is running. Unix time 1683005811
5/02/23 05:36:51z Reset Reason: Power-fail restart.
5/02/23 05:36:51z ESP8266 ID: 15763621, RTC PCF8523 (68)
5/02/23 05:36:51z IoTaWatt 5.0, Firmware version 02_08_02
5/02/23 05:36:51z SPIFFS mounted.
5/02/23 15:36:51 Local time zone: +10:00, using DST/BST when in effect.
5/02/23 15:36:51 device name: IotaWatt
5/02/23 15:36:54 Connecting with WiFiManager.
5/02/23 15:38:06 HTTP server started
5/02/23 15:38:07 WiFi connected. SSID=ASUS, IP=192.168.0.74, channel=11, RSSI -81db
5/02/23 15:38:07 timeSync: service started.
5/02/23 15:38:07 statService: started.
5/02/23 15:38:07 Updater: service started. Auto-update class is MINOR
5/02/23 15:38:07 dataLog: service started.
5/02/23 15:38:10 dataLog: Last log entry 05/02/23 15:36:05
5/02/23 15:38:12 Updater: Auto-update is current for class MINOR.
5/02/23 15:38:12 historyLog: service started.
5/02/23 15:38:13 historyLog: Last log entry 05/02/23 15:36:00
And thatâs it. So far no Wi-Fi disconnections reported, something I would regularly see in the logs before.
As to Home Assistant, it is now populating the new day as normal, so itâs just the historical data for last couple of weeks Iâll need to tidy up.
A promising start.
Just some more info on this one Bob.
I logged into a laptop i sent up there with @wattmatters and watched the logs on his Telstra Firewall - it saw the requests from the IOTAWATT when it booted up and asked for a DHCP address (which the OP has set as a static assignment in the Firewall DHCP server) - it then replied to the request but it appears as if the IOTAWATT never receives the DHCP response and then eventually times out and goes back to its fallback AP mode (192.168.4.1) and its own SSID.
So i have loaned the OP a spare ASUS router i had lying around and we have put this into pure AP mode with its own 2.4GHz SSID - this router is attahed to the main Tesltra unit through Ethernet - the IOTAWATT was able to attach to this SSID straight away and then the AP forwarded on the DHCP request and response and the IOTAWATT was happy
At this stage i am putting this down to something weird with the Telstra mesh implementation (the OP has had other WIFI issues in the past with Tuya/ESP8266 style devices)
I will leave the setup as is for the next week or so and then if stable we can decide if the OP wants to try and do some more troubleshooting (i have sent up a laptop with a WIFI dongle that will do promiscuous mode) so i can do a wireshark capture if there is interest - or if we call it a day and move to replace his current wireless setup
Craig
Iâm more than OK to be the experimental subject if we think it can add the collective troubleshooting knowledge. I am mindful though of how much of your time this takes up.
As to my HA data, I was able to remove the erroneous negative energy values however HA does not have a way to upload historical sensor data which is a shame because itâs all available in the IoTaWatt.
Good bit of sleuthing, and rewarding in that connection can be setup and maintained using the ASUS router. That the DHCP handshake fails with the Telstra AP and not with the Asus AP while using the same DHCP server in the Telstra router indicates to me either a lower level TCP incompatibility or some routing issue to the Telstra AP. I would guess that even a simple wallplug AP wired in with ethernet would work in the place of the Asus router.
In any event, there is nothing I can do from the IoTaWatt side as the connection and DHCP handling is at a lower level than the IoTaWatt firmware and seems to work everywhere else.
1 Like
Trying hard to learn stuff but not sure itâs working!
No change this morning - all still connected and no further log updates.
One thing I donât quite follow with this temporary set up - when I look at the Telstra routerâs set up page, the IoTaWatt is no longer showing in the routerâs device list, nor in the list of static leases I had assigned. It may be we deleted the static assignment from the Telstra router, I canât recall.
If I use the IP address 192.168.0.74 or iotawatt.local, then it goes to the IoTaWatt screen as normal. But that IP address no longer shows up in the Telstra routerâs device list.
So if the Telstra router is still the one assigning DHCP, then I wonder why it no longer appears on the Telstra routerâs device list?
Maybe I just need more caffeine to recall what Craig did!
No definitely should be getting its static IP through DHCP on the Telstra unit - the ASUS is in dumb AP mode
Anyway - note down that you can not see it on the Telstra unit and if we have a weeks stable operation that can be the first thing we put back in - the static assignment and see if it makes any difference - i can not see how but funnier things have happened !
If you want to confirm - go to the diagnostics page of the Telstra unit and monitor the DHCP logs and then restart the IOTAWATT - you should see the DHCP request come in
Craig
1 Like
It reappeared in the Telstra routerâs device list this afternoon when I checked. Weird.
I re-added the static lease but the router wanted me to reboot and it wasnât a good time to shut it down so I removed static lease for now. I have a DHCP lease time of 1 day so it should hang on to it for now.
I did that, eventually found something in the logs although I profess to not knowing what it means. Tried to highlight the lines related to the IoTaWatt MAC and IP addresses:
Thu May 4 16:18:29 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
**Thu May 4 16:18:29 2023 daemon.info dnsmasq-dhcp[27745]: DHCPDISCOVER(br-lan) a8:48:fa:f0:88:a5**
**Thu May 4 16:18:29 2023 daemon.info dnsmasq-dhcp[27745]: DHCPOFFER(br-lan) 192.168.0.74 a8:48:fa:f0:88:a5**
Thu May 4 16:18:29 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
Thu May 4 16:18:30 2023 daemon.info dnsmasq-dhcp[27745]: DHCPDISCOVER(br-lan) 34:ab:95:3f:eb:4f
Thu May 4 16:18:30 2023 daemon.info dnsmasq-dhcp[27745]: DHCPOFFER(br-lan) 192.168.0.156 34:ab:95:3f:eb:4f
Thu May 4 16:18:30 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
Thu May 4 16:18:30 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
Thu May 4 16:18:30 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
Thu May 4 16:18:30 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
Thu May 4 16:18:30 2023 kern.warn kernel: [IFE::] Evict flring 146 {e0:89:7e:62:4b:06 tid 6} wridx [curr 12 last 12]
Thu May 4 16:18:30 2023 kern.warn kernel: [IFE::] Evict flring 148 {a0:80:69:a3:a7:41 tid 6} wridx [curr 4 last 4]
Thu May 4 16:18:30 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
**Thu May 4 16:18:31 2023 daemon.info dnsmasq-dhcp[27745]: DHCPDISCOVER(br-lan) a8:48:fa:f0:88:a5**
**Thu May 4 16:18:31 2023 daemon.info dnsmasq-dhcp[27745]: DHCPOFFER(br-lan) 192.168.0.74 a8:48:fa:f0:88:a5**
**Thu May 4 16:18:31 2023 daemon.info dnsmasq-dhcp[27745]: DHCPREQUEST(br-lan) 192.168.0.74 a8:48:fa:f0:88:a5**
**Thu May 4 16:18:31 2023 daemon.info dnsmasq-dhcp[27745]: DHCPACK(br-lan) 192.168.0.74 a8:48:fa:f0:88:a5 IotaWatt**
**Thu May 4 16:18:32 2023 daemon.info dnsmasq-dhcp[27745]: DHCPREQUEST(br-lan) 192.168.0.74 a8:48:fa:f0:88:a5**
**Thu May 4 16:18:32 2023 daemon.info dnsmasq-dhcp[27745]: DHCPACK(br-lan) 192.168.0.74 a8:48:fa:f0:88:a5 IotaWatt**
Thu May 4 16:18:32 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
Thu May 4 16:18:32 2023 daemon.warn mcsnooper[8174]: Ignoring MLD pkt on non snooping enabled bridge interface lan
Thu May 4 16:18:32 2023 daemon.debug ledfw[4512]: LED callback with event 'mobile_bars1'
Yep you can see it come in with the request and then the address assignment
then it comes back to register its name with the DNS server as well - all looks OK there
Interesting that you are getting MLD packets - unless that is my laptop sending them out.
Lets leave it until next week and see if it remains stable
Craig
1 Like
All still working fine.
One thing I noticed from the IoTaWatt log is a change of the ASUS Wi-Fi channel.
When we first connected to the ASUS router the IoTaWatt log shows:
5/02/23 15:38:07 WiFi connected. SSID=ASUS, IP=192.168.0.74, channel=11, RSSI -81db
While after the test restart the day before yesterday it connected to a different channel:
5/04/23 16:18:32 WiFi connected. SSID=ASUS, IP=192.168.0.74, channel=7, RSSI -85db
I donât know the significance of this, if any. Just seems odd to me that there would be a change of Wi-Fi channel.
Prety much expected - i assume from the logs we saw previously with the Telstra Mesh that they appear to change WIFI channels quite often - one of them has probably landed on the same channel as the ASUS and it has decided to move worth keeping an eye on - but i would expect to see that happen - mine at home (different i know compared to your location) always bounce all over the place depending on what the neighbours are doing
Craig
By default ASUS will change channels. You can fix it by making the channel constant, but there is generally little need to, if things are working.
OK, thanks. Learning more every day.
Still working and I have all my data.
Yesterday I had to power cycle the IoTaWatt a couple of times.
I rebuilt my off-grid systemâs battery compartment and since the IoTaWattâs power is normally supplied by a dedicated off-grid power outlet which was going to be down for the duration of the rebuild, I changed it over to a grid power supply, then again last night to revert back to the off-grid supply after I had finished the (big, painful, body aching) job.
IoTaWatt connection dropped out this evening for 15 minutes.
Cause: Microwave oven. IoTaWattâs Wi-Fi signal is relatively weak, weak enough for the microwave to interrupt it.
Otherwise its been doing well.
With respect this appears to be anecdotal diagnosis. Is it repeatable?
I would say it might be time for a new microwave too. Also, your network is clearly not good enough if a normal microwave can make it stop working.
This is the reason I suggested a small access point reasonably near the Iotawatt location. The Iotawatt is part of a larger system and it seems all of your Iotawattâs issues are most likely caused by deficiencies in the system it is in.
Thanks, yes fair comment.
Itâs something I have anecdotally noticed before with some other devices but have not performed actual tests for validation. I hadnât previously noticed it with the IoTaWatt. I just wanted to make an observation note and plan to validate.
Itâs typically those devices with weak signal Iâve observed have issue before.
In this case the temporary network set up with the Asus router we are using for testing the IoTaWattâs network connection has been performing well but the signal strength is on the weak side.
Itâs just I happened to be monitoring IoTaWatt data when the oven was turned on and saw the loss of data flow. As soon as the cooking was completed the data stream came back. Refreshing the IoTaWatt status page while cooking would result in this:
Or not being able to show anything. Looking at the data it shows signs of signal loss.
I donât have a power monitoring plug on the microwave oven, else I would be able to identify the exact times it has been used over the past week and go back to look at the IoTaWatt data to see if there is a pattern with signal loss.
I will attempt to validate.
Maybe!
Itâs not an uncommon problem. Googling âWi-Fi and Microwave ovenâ will lead to plenty of info on it being an issue with 2.4 GHz networks. Some other home appliances apparently can cause similar issues.
Thanks, yes I have noted the access point suggestion before.
I do already have an access point located near the IoTaWatt on my normal network, and it provides a strong signal at the IoTaWatt, but as we discovered my network has been unable to maintain or establish a consistent connection with the IoTaWatt (reasons unrelated to the microwave oven).
Hence why we are using a temporary set up with the ASUS router Craig has kindly provided me.
This is to test whether the IoTaWatt is able to maintain a stable connection using a different router. The physical location of this temporary router set up cannot really be changed.
But it has been working well whereas my other network just wonât establish connection with the IoTaWatt. Iâve no idea why, it just doesnât.
The end result is most probably going to mean replacing my ISP supplied network with different router and mesh/access points but with Craigâs help we are trying to see if we can understand why Iâve been having such issues.