My 4 Imps has stopped sending the correct temperature since June 23

I have 4 imps with DS18B20 sensors, after Scheduled Maintenance 23 June all stopped sending the temperature to my server and show only
2015-06-26 22:36:08 UTC + 2 [Device] Trigger All Devices to do temperature conversion
2015-06-26 22:36:09 UTC + 2 [Agent] 0

Should show like this
2015-06-20 13:00:01 UTC + 2 [Device] Trigger All Devices to do temperature conversion
2015-06-20 13:00:02 UTC + 2 [Device] # 01: Family: 28 (DS18B20), Serial: 000003c90f24, CRC 55, Temp: 26.38
2015-06-20 13:00:02 UTC + 2 [Agent] 26,375

Use the code in this thread:
https://discourse.electricimp.com/discussion/comment/19078
What could have gone wrong on all four at the same time?

It’s likely your agents were restarted and lost their context. This Data Persistence article has some information about how to deal with agent restarts, or post your agent code and we can take a look.

Agent code
`device.on(“senddata”, function(data) {
// Set URL to your web service
local url = “http://www.temperatur.nu/rapportera.php?hash=XXXXXXXXXXXXXXXXXXXXXXX&t=”;
// Set Content-Type header to json
local headers = { “Content-Type”: “application/x-www-form-urlencoded” };
local url = (url + data);
// encode data and log
local body = http.jsonencode(data);
server.log(body);

// send data to your web service
http.post (url, headers, body).sendsync();

});`

What are the mac addresses of your imps please? Have you tried power cycling any of them?

I have power cycled them several times. But two of them is two hours away from me but at least one of them is power cycled.
0c2a69023831
0c2a69023865
0c2a69070d91
0c2a69070883

Ok, I’ve ordered a couple of those sensors and will try to repro the issue when they arrive.

The components arrived this morning and I confirmed that your device code works with impOS 30.22 but not 32.10, which your imps also received on 23 June.

However the code in @smittytone’s one-wire article does work with impOS 32.10.

The difference is that you are missing calls to uart.flush() after each call to uart.write().

We made a lot of improvements to uart for impOS 32 so without the flush I think your write() may now still be in progress when you attempt to read(). This makes owSearch() go wrong and your while() loop gets stuck. You might therefore still need to power cycle the imps after updating the code.

Can’t wait for the fix infinite while() loop hang.

That is the only reason I manually had to go to an imp and power cycle it.

Maybe leave while() as it is, and instead make another function that takes an argument for setting timeout. I tried to make my own timeout handling, but it was showing down the loop too much.

Thank you very much philmy, I modify my code whith your solution and it works fine!
:-bd

So you know, we’re working on converting the 1-Wire code to an Electric Imp library, so that should save you the hassle to maintaining the core code.