Hello,
I was reading about the temperature and humidity sensors here on the store page.
On the store page, it says that you are able to send json formatted commands to configure settings. They have an example “{“interval”:2000}”. Is there a list of any other commands that these sensors can use or is that the only one? There doesn’t seem to be a list anywhere in the hardware documentation.
My main thing I would like to accomplish is the ability to get these devices to power cycle themselves without having to go out in the field. They will stop transmitting data but will still be connected to our networks and the only solution we have found so far is going out to them and power cycling. As we expand, this is becoming a little bit of a pain, so we are looking for a solution to this problem.
Thank you!
Hi Tanner,
A reboot command could be added to the firmware. Or we could add a setting to perform an automatic reboot on interval. Which would you prefer?
Thank you,
Travis
Hi Travis!
I think having them automatically reboot would be super ideal for our use case.
We’ve currently deployed 53(and much more to come) so having a hands-off approach might be best for our team so can keep expanding without the worry of having to power cycle them when the data stops.
Thank you,
Tanner
Hi Tanner,
I find it interesting that they require a power cycle occasionally. I have not had reports of this from other users. Are all 53 displaying this behavior? How often is this reset required?
I have absolutely no problem adding a built in auto reboot feature. I’m just curious why it is required. The firmware monitors WiFi connectivity, if that passes, then it monitors connectivity to the broker. Do you think it’s possible that the sensors are being improperly disconnected from the broker on an interval? What are you using for the MQTT broker?
Thank you,
Travis Elliott
Hi Travis,
No not all of the sensors are behaving this way. It seems that we have a few problem sensors that exhibit these behaviors. A lot of our sensors have been deployed and never have had a single issue after being deployed. Some of the sensors had issues, got a power cycle, and have been great since.
Here’s an example of a problem sensor (Values in Fahrenheit):
You can see that it was working until around the 1st, quit out and then a little before the 5th, we reset it, and it worked for a day before stopping again.
It still is not transmitting because I haven’t sent anyone out to reset it yet. If I look in our networks right now, find it by mac address I can see the sensor right here:
We are using Cirrus Links MQTT modules in conjunction with Ignition. Looking at the logs, I don’t see anything that completely stands out to me that would be the problem, no messages about our MQTT broker or anything related to the sensors.
I can still remote into that same sensor and access the sensors configuration page by using it’s IP address. If I access that configuration page, hit save settings, is that essentially a reboot?
I’ve tried it on this example sensor and it keeps connecting to the Wi-Fi but is not transmitting anything.
To rule out the broker, I will set up a test this afternoon by creating a new local broker on the same network and pointing the sensor to the newly created broker. If it starts sending messages to the newly created broker, perhaps the broker is the problem.
Sorry for the wall of text 
I wanted to also show an example of a sensor I personally went out and power cycled. It has been working great the past couple of days, here it is:
The only thing I can think of that would cause this is an abrupt internet outage which would result in the TCP socket to the MQTT broker being severed and the connection not being properly closed. I have not seen this but I suppose it’s possible. In that case the sensor would not know the MQTT connection was lost and would continue operating as though everything was fine. It would however know that publishes to the broker were failing so the LED should be flashing Red rather than green. Do you know if the LED is flashing Red when this happens?
An automatic reboot would be a sledge hammer way of fixing the issue. I would like to find the root cause and fix it properly if possible. Let me know what the LED does in these instances.
Okay, so I found out a few things today that are interesting.
So, I talked to the intern I have been having reset these sensors today, and he told me that most of the time the sensors are flashing white. Which would mean that these sensors are just truly having trouble connecting to the access points we have deployed (I think). Still, power cycling them has been the ticket to resolving those issues.
The last picture I sent was the one I power cycled myself. When I went out there, it was flashing green. I logged into the broker and saw that even though the light was flashing green, it still had not talked to the broker for a while. I’ve been going off the assumption after that sensor that they have all been flashing green, but I guess not.
Not exactly sure if either of those scenarios are helpful in debugging.
We did receive a batch of sensors from you guys today, and I hooked up a brand new one to a separate hosted mosquitto broker that I set up this afternoon. That new sensor transmitted fine to the new broker. I then logged into the first picture I sent you through the IP address, repointed it exactly to the same broker and nothing. Both hooked up to same network, broker, etc. the only difference being their client IDs.
I guess my last test, and I can do this tomorrow would be to go out to the sensor that is being displayed in the first picture. It will be a bit of a trip, but I can report back with what that sensor is flashing whether it being white or green. I’m guessing it will be green though if I can get to it through the network and see it in our Wi-Fi manager. Either way, I will report back tomorrow with my findings.
Yeah, if the LED is flashing white then it’s having trouble connecting to the WiFi network. If it’s flashing Green then there is another issue.
I will add a setting to the UI that would allow you to set the automatic reboot interval so the sensor would just reboot every so often. Setting this value to 0 would disable this reboot. What would you want it set to by default? I will have you set it in seconds. You will be able to update the firmware on the sensors you have currently once it’s available.
Thank you Tanner,
Travis Elliott
If we can set a default time 3600 seconds would be great! If I have them resetting themselves every hour, I can really set it and forget about it!
I still plan on going and checking that problem sensor later today. I’ll let you know what the light is flashing so we can try and get a better understanding of the issue.
Sounds great Tanner. I’ll try to get that firmware update done today.
Thanks Travis!
We just got back from checking on two of the problem sensors. Both were flashing red three times. So, I guess they were having issues connecting to the MQTT broker. Both were power cycled, and both are transmitting fine again.
I know this is probably not super helpful, because now I’ve seen 2 separate codes that were all fixed with a power cycle and another person has seen the white light that was fixed with a power cycle.
Wish I could give you more information on these.
Thanks for the update Tanner. I am adding the automatic reboot interval setting to the firmware now.
Hi Tanner,
I just uploaded v1.0.6 firmware to the firmware repo here:
This has the automatic reboot feature. It is set to 3600 seconds by default. You can change the setting through the WEB UI if needed. Setting the value to 0 disables the reboot. Auto reboot will not execute if the sensor is in configuration mode(flashing Blue LED). I do not recommend setting this value to anything less than 10 seconds as that could cause problems(not being able to access it), but I did not strictly forbid it.
If you have a test unit there I would recommend updating it to see if it works as intended. Let me know what you think.
Thank you,
Travis Elliott
That’s awesome, thank you so much. Will test it out on one and then start rolling it out to the rest if the test is successful! Thank you Travis!
@TravisE_NCD_Technica You might consider an auto reboot on all boards (default to 0!).
3 times now we have had a wifi Pro XR Lite simply stop talking for a while. It shows up as connected to the nearby AP in the Ubiquiti dashboard with an RSSI similar to 2 others close by. It pings ok. (Sorry, not sure if the same unitor different unit). Twice it came back on its own. This last time we could access the wifi module with NCD base - it wouldn’t list config or apps at that time – but magically after doing that we discovered it was talking normally to our system again!
And as tanner in this thread, it’s time consuming and VERY embarrassing if we have to travel and reset devices in front of the customer.
FYI:
PR60-1_R85PL Pro XR Lite 8 relay board
PR55-22 Wifi module
Update seems to work exactly as intended!
Thank you so much!
I do think I bricked one of the devices in my testing. I noticed that it was loading the data that was contained within the spiffs.bin file through the json data at the top of the file. In an attempt to load our own data so I could update all the sensors remotely I replaced some of the config data with our own and I think I missed a colon.
The sensor is flashing a very faint red light in increments of one. Is there a way to get it back to the factory settings? I noticed there is a micro usb port on the board.
The rest of the 20 sensors at the lab went great when I used the exact provided firmware.
Since we have around 60 in a 2-mile radius we are only going to deploy the updates when the sensors start needing to be reset, so we don’t have to drive out to each and every one currently (Most are working fine anyways).
Hopefully after this update rolls out to some of the problem sensors in the field this problem starts to go away.
Well, the firmware update works as intended, but I’m not sure why a few areas are still having issues. We still have to power cycle them by hand for some reason even though they are updated.
I have even swapped two of the sensors with brand new ones to rule out the sensors themselves and the issue persists. The one thing I can say with certainty this time, is that they are all displaying the same status code. Two flashing red lights. These sensors are in enclosures where the only people who have been opening them are us. They don’t even require retightening of the probe, just a hand power cycle for some reason. I have also tried with one of the sensors to tighten the probe on one as much as I possibly could and the other one just power cycling. They both ended up with the same with the 2 red flashing code days later.
Is there any sort of logs on these devices?
Is there any json/web commands I can send them to get them out of this loop?
I’m guessing the firmware power cycle leaves them with some sort of memory that they are not getting completely cleared with the firmware power cycle.