Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Randomly stop broadcasting (vESPrino v1.16 build20170228)
#11
Could you be a bit more specific in explaining how to properly set-up the logging feature?

1. I copied the source script and saved it as httpsrv.js in the root folder of my Pi.
I'm using PM2 to start the script but after about 10 seconds the script errors out and stops working.
(Log: https://pastebin.com/Gt7thZsd)
I filled in the IP (without port) of the PI in the config tool under vESPrino, Logging HTTP Dest.

2. I added the url to the Custom HTTP config (It's exactly the same as reporting the Co2 except that it ends with the variable Runtime. Is it correct to have both urls there? It seems to me that the CO2 variable value would just overwrite the runtime variable value.

3. Do you want me to grab a chair and sit next to the device or something?
The RGB led is very very very faint and can hardly be seen.
Also, I'm colorblind and Lila, Purple and Blue are all the same color to me (in this particular case), I see no difference on the LED...
Reply
#12
1. > i am not familliar with PM2 for running nodejs scripts.
The script listens by default on port 8080
see "const PORT=8080"
maybe if in your RPI something is already listening on this port - the http server cannot bind to it and this is why it fails
Also in the vESPrinom you need to configure the destination with the correct port (and i had forgotten - just make sure that it ends with some path, e.g. http://10.44.11.11:4444/xxx, w/o /xxx it seems to not work)

2.) i believe you would need to change also the "idx" parameter, to another one, so that it does not get overridden

3.) nooo.. i would rather expect that once it stops working after N hours, you would check what colors the led shows (e.g. wait 2 minutes, until the next iteration begins), or see if it is still logging on the logging destination (and then what would it dump), or if the Runtime value is sent, but the CO2 not

4.) to make the led more visible, go again to ConfigTool/vESPrino and there in "Brightness Override" choose e.g. 20. I will change the colors to be e.g. White, Blue, Orange in the evenening


And finally, you can still downgrade to some of the previous firmwares, as described here
http://forum.vair-monitor.com/showthread.php?tid=18

This way it will be clarified if it is indeed a software or a hardware issue
Reply
#13
Okay, thanks for the quick reply.

1. I changed it to port 4444, changed the url in the logging http dest field.
What is with that /xxx though? Where does it output the log? Does it dump to a file? I don't see it anywhere in the script?
I don't think the script or the monitor has any rights to create a logfile on my pi...

2. I created another virtual sensor so that the runtime outputs to a different counter (tested, verified and it works)

3. Alright.

4. Did that too.
Reply
#14
alirghht, than let's see what 2.) will show

as for 1.) the scripts outputs to standard out, so you may need to redirect it to somewhere
(i have tested it on windows, where i just open a command prompt and check what it shows, this is why i haven't provision more documentation about those cases)

The /xxx is because the HTTP Client on the WiFi module of the Device somehow does not handle very well urls like http://host:port, and it took me quite a while until i realize that there need some kind of query path... else - the script just logs the content of the request that comes - doesn't even check the path
Reply
#15
This is what the HTTP log showed me:
https://pastebin.com/B2qfj4jw

The extra IDX with the %RUNTIME% Variable did log some data too.
I powered the monitor up at 13:05 GMT+2, The device reported the following values:

Time - Runtime - CO2
13:05 - Nothing out of the ordinary
...
17:55 - 17639 - 603
18:00 - 17909 - 601
18:05 - 211 - No change
18:10 - 469 - No change
...
19:05 - 469 - 601

after that, nothing was reported at all...

As for the RGB LED (in debug mode):
I noticed the device stopped responding at 21:00.. Went to the room with the vair monitor and...nothing... I've sat next to it for like 10 minutes in a dark room...


A quick look at the log showed me that the device tried to go into Deep Sleep mode, woke up from it as if the entire device rebooted and then after a while it went back into sleep mode and died....
Reply
#16
hmmm that is strange

i think it is best to send you a new module (along with a new RF sender, just in case) and try it out
i have your address
Reply
#17
(03-28-2017, 03:27 AM)admin Wrote: hmmm that is strange

i think it is best to send you a new module (along with a new RF sender, just in case) and try it out
i have your address

You can leave the RF out, I rely on Wifi to send my data.
Before you do though, what is the nominal power consumption of the device? Just to make sure it is not the power adapter...
Reply
#18
it is up to 400 ma during startup or sending data (in very short 100 ms bursts)
but this shouldn't be a problem when powered via 5v, unless you have some very crappy power supply (though even with 1$ chinese ones it is fine)
only the CO2 sensor would not report data if the voltage drops below 4.6v, but then still, the device would boot, and would send the RUNTIME value
Reply
#19
(03-28-2017, 10:16 AM)admin Wrote: it is up to 400 ma during startup or sending data (in very short 100 ms bursts)
but this shouldn't be a problem when powered via 5v, unless you have some very crappy power supply (though even with 1$ chinese ones it is fine)
only the CO2 sensor would not report data if the voltage drops below 4.6v, but then still, the device would boot, and would send the RUNTIME value

I use one that was supplied with a samsung tablet, it outputs max 1.0A so that should be good.
Reply
#20
Today the device stopped with a Runtime value of 58211.
As you can see, the device stops at totally random intervals.
Reply


Forum Jump:


Users browsing this thread: 3 Guest(s)