Temperature Humdity sensor JSON Commands

Software
42

Interesting. That is a lot of resets but it seems to still be working? Temperature is supposed to be -19 F?

A reset is attempted any time communication with the probe fails but that’s a lot of failures. We could attempt reducing the clock speed of communication with the probe to see if that improves communication reliability.

The reset counter does not reset to 0, it just continually increases for each reset. However it will reset the counter on reboot so if you have the sensor configured to reboot on interval that would explain why the counter is reseting. I am not saving the reboot counter to non volatile memory, just RAM memory.

43

Temperature should not be around -19F. It should be more around 120F. Both sensors ended up failing and displaying exactly -19.5.
Today is actually my one day to update most of these sensors, so I’ve collected around 20 of them and have them in the lab right now.

44

Hi Tanner,

The only thing left I can think to do is to do a manual reset of the communication interface via hardware. I have implemented a hard reset along with the soft reset in the firmware. The number of hard reset attempts will be in the sensor data packet labeled hard_reset_counter. If a soft reset fails to recover the sensor this hard reset procedure will be attempted.

I also reduced the I2C clock speed from 100kHz to 50kHz to see if that makes any difference. Please update to 1.0.9 and let me know what you find.

Thank you,
Travis Elliott

45

Sweet! I’ll start applying it.
Thank you again for your patience and working through this issue with me.

I do have one question. So every time I’ve done an update, I always do the firmware and then the spiffs file. I was just wondering if the spiffs were absolutely necessary. I only ask because some of these sensors are in really hard to reach places, some I only have the opportunity to reach maybe one time a month. The firmware portion is always fine since it keeps the original settings, but the spiffs clears them. Then we have to go out there, take the cap off, put them into config mode and reapply the settings. So is it possible to get by with just the firmware portion? Or do they always have to be done in conjunction.

Seriously, thank you again. They want to roll this project out to other plants so it’s nice to know this product has support.

Thank you,
Tanner

46

Hi Tanner,

I have not modified the SPIFFS since we initially added the auto reboot feature. All updates have been only to firmware so that is all that is required to update. So if the device is <1.0.6 you will need to update SPIFFS, otherwise it is not required.

Keep us updated Tanner. Bumps in the road like this are what make products better!

Thank you,
Travis Elliott

47

I don’t want to jinx it, but version 1.09 has been completely stable. I’ve deployed it to 44 sensors and not a single one has had an issue yet. Furthermore, the most troublesome sensors since initial deployment have been working great. I think that update was the fix. Thanks again Travis, if we run into any issues down the line I will return to this thread and shoot you a message.

Thank you again,
Tanner

48

Hi @tanner,

Great to hear!

I did a little house cleaning on the firmware and made a couple small improvements. I just published firmware 1.0.10. Although if everything is working as expected and you do not want to update the sensors I completely understand.

  1. I fixed an issue with the RGBLED where it was not always updating state based on operation of the probe.
  2. Renamed some variables soft_reset_counter and hard_reset_counter.
  3. Added a variable indicating the connection state of the probe.
  4. The sensor will now continue to report to the broker on interval even if the probe is not working. This should allow for monitoring of issues remotely. Before if the probe was not functional the sensor would not check in. This was an obvious issue now that I think about it.

Here is a sample packet from the device operating normally with the probe properly connected:

{"data":{"temperature_c":24.08,"temperature_f":75.35,"humidity":35.92,"transmission_count":2,"probe_connected":1,"soft_reset_counter":0,"hard_reset_counter":0},"info":{"ip":"192.168.1.133","ssid":"Zoe-Wifi","mac":"48:E7:29:A6:0B:D4","rssi":-40,"firmware":"1.0.9","interval":5000,"name":"NCD-0BD4","timestamp":1731092898}}

Here is a sample packet published to the broker when the probe is disconnected. Notice the probe_connected variable goes to 0 and the hard_reset_counter and soft_reset_counter variables are increasing.

{"data":{"temperature_c":0,"temperature_f":0,"humidity":0,"transmission_count":3,"probe_connected":0,"soft_reset_counter":1,"hard_reset_counter":1},"info":{"ip":"192.168.1.133","ssid":"Zoe-Wifi","mac":"48:E7:29:A6:0B:D4","rssi":-44,"firmware":"1.0.9","interval":5000,"name":"NCD-0BD4","timestamp":1731092909}}

Also when the probe is not connected all temperature and humidity values drop to 0 although the probe_connected variable should be checked to ensure proper operation as 0.00 readings are theoretically possible.

Thank you so much for your patience and feedback in helping to improve this product.
Travis Elliott