Thanks to all previous replies to my questions. I’ve been able to nut out some issues and fix many bugs. Over that last 6 months all my WebThing-Arduino ESP8266 devices have worked well, TOO WELL in fact, that now I have been thrown a serious curve ball.
The network mesh installation that I have been connecting to had a serious failure. All device connections were lost. Over the course of several hours I have managed to resurrect everything EXCEPT the custom ESP8266 based devices programmed with WebThings-Arduino. I have been unable to reconnect any of the ESP8266 WebThings-Arduino based devices.
I have gone over the same procedure which was used originally, although some IP addresses have changed, and these have been updated. I can test the devices by simply getting a response through using Firefox and the entering the device URL… One such device simply turns on a LED lamp, its JSON response is;
[
{
“id”: “led”,
“title”: “Device LED”,
“@context”: “https://iot.mozilla.org/schemas”,
“base”: “http://192.168.5.75/”,
“securityDefinitions”: {
“nosec_sc”: {
“scheme”: “nosec”
}
},
“security”: “nosec_sc”,
“@type”: [
“OnOffSwitch”,
“Light”
],
“links”: [
{
“rel”: “properties”,
“href”: “/things/led/properties”
},
{
“rel”: “actions”,
“href”: “/things/led/actions”
},
{
“rel”: “events”,
“href”: “/things/led/events”
},
{
“rel”: “alternate”,
“href”: “ws://192.168.5.75/things/led”
}
],
“properties”: {
“on”: {
“type”: “boolean”,
“@type”: “OnOffProperty”,
“links”: [
{
“href”: “/things/led/properties/on”
}
]
}
},
“href”: “/things/led”
}
]
Which on inspection, seems to be correct. Unfortunately, on the things Gateway panel, the “Device LED” thing is greyed out and not responsive. This the same for all of the other ESP8266 devices. Using Fing to sniff the network, all devices are connected and have IP addresses.
When hovering over the thing icon, not the body of the “Device LED” the line reads;
https://fleatechoz.webthings.io/things/http---basicled.local-things-led
Is this correct? All other devices, including Tasmota based switches (third party) are working as expected.
I am at a loss for why this is happening.
I can provide more detail if it will help.
Thanks for your patience.
Have you try to re-adding the device?
Yes. Several times. Removing and clearing all settings. No luck.
I have found some notes on the ESP8266 devices, which may offer a solution, I’ll test these tomorrow.
Thanks.
good keep us updated about it! and the solution too if it work
Update on Things and Mesh Network.
After several days of tracing the Mesh network configuration, resetting and reinstating the WebThings (all ESP8266 based devices), this is where I am at…
1: Once the Mesh was reset and reconfigured, the only items that the WebThings Gateway was not able to reconnect were the ESP8266 WebThings with code built from the WebThings-Arduino library. These had to be manually added by URL. Adding via the WebThings AddOn was not working. All existing entries had been removed.
2: The Mesh network had reassigned the IP address for every device, most likely due to “Fast Roaming” being the default at start-up. This I have no control over. There is no option to set the IP address in the Mesh configuration tool(s) for the ESP WebThings. I may look at hard setting the IP address for each ESP WebThing within the code.
3: In reviewing the code examples and how the ESP WebThings connect, I’ve begun to look at a more robust way of structuring the code for such disconnection events. Still learning the nuances of the ESP devices.
At this point I’m testing several ideas, some successful, some a dead end. The basic configurations as as follows.
1: All devices are configured with a backup battery to help skip over any power glitches.
2: The ESP8266 modules used vary from an Adafruit Huzzah! ESP8266 module, several fixed installs using the Wemos D1 Mini Pro, and some test sets which use the Seeed Wio Link.
4: The Wemos D1 Mini Pro’s have been the most reliable. No idea why. These were the original test units with the original WebThings-Arduino code, only modified for the type of sensor fitted.
5: The Huzzah based units are MultiLevel configurations with a signal fail protocol added in case of disconnection. Moderately stable. Have to be manually reconnected.
6: The Wio Link devices are now my core test beds as I have added OTA capability and web based manual IP setup options. At present buggy but working. Trying some new ideas.
All in all, getting there slowly. Once I have better structured working code, I’ll post to my Github page.
For now, still weeding out Mesh issues. If only I can work out roaming functions for the ESP8266 modules.
Thanks bearing with the long reply.
Cheers all.
Forgot to add.
When adding WebThings-Arduino based devices, the most common error is [400: Bad Request Error]. Still trying to work out why.
for your IP situation, is it possible for you to code a fallback ip address? could help!
That’s one of the options I’m investing to get past the current issues.
Cheers.
Some more points…
Using “Fing” to scan the network on my tablet. I get confirmation of connected things;
basicled: a simple led switch, IP: 192.168.5.73, Huzzah 8266.
bme680weather: BME689 Sensor, IP: 192.156.5.206. Wio Link 8266
adapter: PIR Motion Sensor, IP: 192.168.5.241, Wemos D1 Mini Pro
weathersensor: DHT20 Weather Senor, IP: 192.168.5.248, Wemos D1 Mini Pro
Typing the IP address into Firefox, http://192.168.5.xxx, I get a response, a JSON data packet, from all devices except “basicled”. Even when reset and reconnected, “basicled” appears for a short time in the “Things” list, it works, then it disconnects, obviously due to a non-response during the polling cycle.
The code for “basicled” is the base test example taken from webthings-arduino “led”.
All other devices use the same basic code structure, excepting where changes are required for the senor being used.
This is where I am focusing on the current issue.
Thanks for putting up with the dramas.
Cheers all.
could it have some conflict on the gateway side??? maybe a device id stuck somewhere so when it try to pair, it got issue???you should try if it work on a fresh gateway install(a docker image could be an easy test)
just a tough
Final Update and Resolution…
After a few months of rewrites and updates, this is what I have managed to work out. I’ll be brief.
-
I have no control over the way that the Mesh Network which the WebThings connect to, as it is part of a fire-walled sub-net used primarily for systems monitoring and control throughout the building lighting and HVAC.
-
To maintain channel and connection integrity, the Mesh decides which node will connect to the WebThings. This is based on signal strength and Mesh sub-net capacity. So, invariably, the IP address may change. When this happens, the WebThings Gateway will lose the connection and may not be able to reconnect.
To help maintain integrity of the WebThings, I have decided on the following;
The IP address of the Gateway is now a fixed and known WIFI address. The Gateway is is visible through the firewall which the Mesh connects to on its own port.
The WebThings are now all coded with a fixed IP address and this is manually set within the Gateway. If a WebThing loses connection, it will reconnect with a minimal amount of fuss.
I have also rewritten some of the WebThings code to use code from https://github.com/tzapu/WiFiManager to make managing connections easier.
All in all, things have been behaving.
Future work involves tidying up some sensor code and more rules and Node-Red additions on the Gateway.
Cheers everyone and many thanks for the assistance.