Indoor temp

Any other WD problems pale into insignificance: my wife has just asked if I’ve turned down the heating thermostats because the WD and Weather34 displays on her iPad show it to be cool indoors when it’s not.

Indoor temp/hum is not something I check very often but, sure enough, it is not being picked up - it’s been stuck for hours, even on the main WD screen. . . and before that it was stuck 0.2C higher for hours. Seems to have been going on for a couple of days.

What could have caused this?

what shows in the separate running wmr200 program for the indoor temp raw data as that comes through

Didn’t check. I presume it showed it was stuck, the indoorlog did. . .

Anyway, I got it back by uninstalling the test .zip update you offered me for flat-lining on 28 September, the only thing I’ve changed recently.

that would not be it I do not think
I would have instead just tried restarting the version you were running

You’re probably right. But, hey, it worked, and the wife was happy.

Seem to have been doing a lot of restarting lately. Flatline? - restart. No clientraw.txt? - restart. No indoor temp? - restart.

By rights, I shouldn’t have to restart WD at all!

try this update
http://www.weather-display.com/downloadfiles/weatherdisplaytest.zip

I did, thanks. WD started, read and decoded the history data and then stalled completely. Data gatherer working fine but nothing getting through to main screen at all - both DQ and DR “lights” stayed red. So I’ve gone back to the original S57 weatherdisplay.exe pro tem - I’m not using either of the offered test versions.

I have asked this before: why does “WMR200 History vers 1.3” always run twice at start-up before handing over to “WMR200 History Data” to decode?

try another update
http://www.weather-display.com/downloadfiles/weatherdisplaytest.zip

re the 2 history windows, one is a separate exe program, that gets the raw data, the other one checks for that being finished and then processes that raw data

OK, test update unzipped and WD started up OK today.

What is this test supposed to do? I’m asking because I’m also trying to pin down the clientraw problem - see separate post - and don’t want to confuse things.

But I was highly tempted to download the test.zip you posted yesterday for the flat-lining problem!

this should fix the indoor temperature and hopefully the flat line issue (WD should detect that and then restart the separate WMR200 data reader)
I will do a test here (by pulling the USB cable)

OK, so it can’t affect the separate clientraw.txt problem because client WD is running stationless.

if the version of WD running connected to the WMR200 stops getting data from the WMR200 then it will stop logging data, which includes the clientraw.txt file

I have tested here pulling the WMR200 cable
WD detects that:
WMR100/200/300 USB no data
Doing checking of time zone calculation
Daylight saving in use
WMR100/200/300 USB no data
Exiting WMR100/200/300 program
Restarting WMR100/200/300 program
WMR100/200/300 USB no data stopped logging 8:53:59 AM

and stops logging data (which will also stop the clientraw file)
problem is, even after putting back in the usb cable, WD is not trying again to restart the WMR200 program
I will fix that.standby

build 58 will keep on restarting the separate wmr200 data read program if no data detected now:
http://www.weather-display.com/downloadfiles/weatherdisplaytest.zip

Thanks, Brian, I’ll load that tomorrow. Will it help rick790 with his flat-lining too?

How about a version of WD running stationless?

if that version is using the clientraw.txt that is stop updating, then it will stop getting data

Since then I have installed the later build 58 update you offered, and today I’ve seen an entry in the Event Log for the first time in 3 years:

ERROR: Failed to get data for ‘intemp’ System.Win.Registry at time/date 0:52:26:845 11/10/2017

Is that significant?

not all that significant
I assume things carried on, yes?

Yes, it would seem so.