I updated the configuration program and the device firmware the other day (Friday, I think). Only immediate problem was that I did the configuration program first and it started sending commands with the “!” which confused the old firmware. When I did a factory reset I then had to do the command to reset the wifi manually without the “!” in order to do the “otah” command.
I like the new layout of the configuration utility with the tree-list down the left-hand side: makes it a lot tidier.
I couldn't see where to configure the sampling rate but the default two minutes is fine, really.
What's a bit more disturbing is that it's twice dropped back to reporting all parameters (temperature, pressure, altitude, humidity and CO₂) in %xxx% form rather then numerically. Unplugging it and plugging it again has reset it which is annoying as there's no way to fiddle with it with the config utility without doing that.
I've left it plugged into a USB hub plugged into my laptop in the hope it'll do it again but it hasn't so far.
Hi Ed
When did you upgrade to latest version? as of yesterday morning, build 20161217, you shouldn;t see %TEMP%, %CO2%, etc;;. the firmare no longer sends values if those are no replaced.
Though there was an intermediate version that - once it faild to find some sensor, started to not searching it at all, anf then needed a hard reboot
12-22-2016, 03:01 PM (This post was last modified: 12-22-2016, 03:05 PM by Ed Davies.)
I'm a bit confused now: as of 2016-12-22 Thur 14:57Z my current version is 20161217 but the last %TEMP%, etc, entry in my log files is for just after midnight on the 18th:
What I have had since then is it stop recording on a previously known-good power supply in much the way it does with suspect power supplies. One time when I unplugged it and plugged it in again after such a stop the light went bright red for a while: could it have done a firmware upgrade without my explicitly asking for it?
Just done another update (at 2016-12-22 Thur 15:04Z) to get today's firmware 20161222 (vESPrino v1.16 build20161222). Will see how that goes.
yeah, when it reboots, it automatically checks for firmware update indeed
for now i assume that all devices should get a new release as soon as they reboot.
else i wouldn't scale with keeping track of all the different versions out there
(12-18-2016, 07:40 PM)Ed Davies Wrote: I couldn't see where to configure the sampling rate but the default two minutes is fine, really.
Oops, I see that's at the top of the Settings page. Must have been scrolled down a bit and missed it somehow.
However, with the new version (20161222) it stopped sending soon after 06:39 this morning. The device is still active as I've had a “ping -a” pointed at it for hours and it pings once or twice every approximately two minutes and twenty seconds. I.e., it's logging on to the WiFi router for about one or two seconds every 160 seconds or so.
It's plugged into a power supply (USB wall wart originally for a Hudl Android tablet) which has seemed good in the past. As such it's not plugged into my computer and I'd have to power it off and on again to do that. Before I unplug it are there any other tests I can do other than confirm it's responding to pings while logged in?
i had a couple of spare hours and added a very rudimentar support for online logging.
the device will dump before going to sleep, or after sending data to the configured destinations
the dump is currently performed by sending a POST request to a configured url, and the url is set like this
prop_set "log.dest.url","http://192.168.1.100:8080/log"
then you need to restart
(for some reason it was not working w/o /something after the port)
Hope you had a nice Christmas and didn't spend too long on this actually on Christmas day.
Since my last post I tried it also on a powered hub plugged into my laptop which previously didn't have problems (it did have when it was powered but not plugging into the laptop). It failed once after about 8 or 10 hours, I think it was.
I then tried it plugged straight into my main laptop which has worked without problems for a couple of days.
It's just possible that the problem isn't in the vESPrino but in the networking on my laptop. Very unlikely - Linux is quite good at networking in general - but to reduce the risk that it's something odd mosquitto is doing or something I also moved one of my other processes sending MQTT messages (a little Python script reading a bunch of 1-wire temperature sensors) to my netbook which is connected separately via WiFi. That's been running fine for a few days.
Just now I updated to your new version (vESPrino v1.16 build20161226) and set up the logging as suggested (though using port 9090 as I tend to start web servers on 8000 or 8080 quite a lot). Output is directed to a file called 'debug' so we'll see what's there if and when it fails. I've put it back on the powered hub which failed the other day. Meanwhile, attached is the debug file so far.
