I am just getting around to re-deploying my gateway to handle some plant sensors. I found it rebooting or staying offline so just re-flashed it to 1.8.0.
Here are the relevant looking parts of the logs. I couldn’t really find anything in GitHub or here, thinking “Passive continuous scanning required” might be a clue.
(I think we should also fix the typo in that log message )
in dictates that a device has been received which would require passive continuous scanning - like a BLE motion, contact or button sensor. If you only want to receive and decode your plant sensors, this would not be required at all and would actually be overkill to do continuous scanning.
So if this is the case you might want to use the white-list functionality to only receive the plant sensors, and the device which caused the continuous passive scanning setting should not be picked up any longer and hopefully not cause any reboots.
Thanks for the reply. I did have whitelisting going before starting from scratch, and intend to have some contact/motion sensors as well. I’ll white list the plant sensors for now and start small. I hope I can get the MQTT command to it before the reboot!
I wonder which already existing device, either of yourself or possibly some neighbour, Mit cause this passive continuous scanning request.
because the white-list command needs to be sent as a retained MQTT command it should be retained on the MQTT broker and sent to the gateway again every time it starts up again, so it should definitely be sticking with every startup of the gateway and be registered
Once you have the white-list hopefully preventing the reboots, you might also want to change the interval settings to a more appropriate 1 minute or so, and the scan duration to something like 10 seconds again.
Just make sure that any further commands will need to have the retain flag turned off.
I just had a few minutes to try, and no luck. I can get a whitelist with a single whitelisted device I know is online and I can see that it detected it, but it panics after a variety of different addresses.
Can you also make sure that adaptivescan is false, but this shouldn’t really have happened if you only have one plant sensor in the white-list, as this was caused by the Qingping Motion & Light, which shouldn’t have been published if it’s not in the white-list.
Are you sure you published the white-list correctly to the correct topic and with the proper payload? E. g. did you swap the example default OpenMQTTGateway with the gateway name of your particular gateway?
Yes, if you make sure that erase flash is ticked, but adaptivescan will be true as a default,
The whitelist was correct and applied correctly, but I forgot to make sure it was just a plant sensor. Sorry - quick lunch test. That device had been in my whitelist previously, is currently online and in range, and used to be working. I just saw that it was broadcasting so made it the only whitelisted item.
I changed to only whitelist a plant sensor that is not currently in range, but am still having the error. I also re-flashed and erased/reset all settings from the captive portal.
If it is a Theengs Bridge TBRIDGE01 you should take theengs-bridge environment.
For TBRIDGE02 you should take theengs-bridge-v11.
Once you have the good binary installed configure it with WiFi (without Ethernet first) and let me know if it still crashes at start.
If not you can connect it after to ethernet.
Brought it to my office this morning, which has site-to-site VPN back to my house. Just re-flashed and erased, used a new MQTT topic and it works just fine. No whitelisted items. I’ll bring it home in an hour and see if something crashes it there. It is a TBRIDGE01 which is the firmware I’ve used all along, and I have only connected via wifi.
Without changing anything after having it working at home, plugging it in and watching the serial logging, the device panics at home within 30 seconds.
Unless I am reading the logs incorrectly, it appears to be a different device most times. Of five, two devices appears to cause it twice. Maybe the truncating has something to do with it? The model of the three devices that appear to cause the reboot are down below - two motion sensors and an ibeacon.
I can test in two locations in my house - each about 60 feet away from each other and it crashes in both locations.
Not too sure if you meant to post the B4: “iBeacon”, but what kind of device is the :38?
As the other two are both motion sensors, and you possibly don’t have any of these at the office, and if the third :38 might also be a motion/contact sensor, this could be a pointer as to where the problem might be.
)