Any ideas how emonHub service startup could be delayed on first boot?
I'm currently working on the software for the emonPi. The plan is to use standard emonhub to decode data (in JeeLabs packet format) from the serial port in exactly the same way as with the RFM69Pi.
On the emonPi data received by the onboard RFM69CW (from emonTH, other emonTx etc) will be passed to the serial port in the same way as with the RFM69Pi. The emonPi will also perform local sampling from connected CT's and pass the values to emonhub in JeeLab packet format with a fixed node ID (default 5). As far as emonHub is concerned there will be no difference from and emonPi or an RFM69Pi receiving data from several nodes.
Like on the emonTx V3 the emonPi performs a 10s check of the CT inputs and AC voltage input at startup to decide what's connected and sample accordingly. The issue is when emonHub starts up BEFORE the emonPi is ready then hangs due to 'device communication error'. Could the statup of emonhub be delayed on cold boot?
Re: Delay emonhub startup on cold boot?
Hi Glyn.
I'm not sure how the Pi or emonHub can determine what is a "cold" start without some sort of "time since last run" code. Therefore the delay would need to be added to every start, restart or reboot and unless the code is different for the emonPi it will delay for all emonHub users, neither of which is ideal.
How much time are you short? emonHub is already configured to be the last daemon to start, But If you are only a couple of seconds out then maybe we can jiggle things around a bit or increase the existing delay a little. The existing delays have been kept short for a quick boot-up but another second or 2 shouldn't hurt.
Are you using auto-detect for baud ? The current implementation needs re-visiting as it is not foolproof. This will be looked at once the "b-directional" changes are made for control and MQTT. Does the issue still occur if using a defined baud?
Can the order of setup events be shuffled in the emonPi sketch? or remove any initial serial "chatter" or debug stuff to establish a stable & quiet serial conn sooner ?
I see the sketch actually pauses for 10 secs, is it possible to use a "if not 10s since" loop so that the serial could be setup whilst waiting?
We can certainly add a small delay if that will fix it but I think the 2 unsynchronized startup routines could vary with updates, loading etc and whenever the test is done by emonHub it could clash with a "no response period" in the sketch so the only 100% fool proof solutions would be to make emonHub wait longer than any potential delay for a response, which testing 3 bauds could result in a very long connection routine, or eliminate/reduce the "no response" periods in the sketch. Some delays are unavoidable but any delay in the sketch has to be accommodated 3 times with room to spare in emonHub's auto detection.
Paul
ps I notice you are using "v" to change voltage in the sketch, this is used by jeelib to return the firmware version and therefore may cause unexpected results. although it should only be an issue if the 'v' get prefixed with 1 or 2, which shouldn't happen but it's not impossible.
Re: Delay emonhub startup on cold boot?
I use
to determine uptime and hence cold boot; you can then use a delay as needed before starting it up
Re: Delay emonhub startup on cold boot?
Wouldn't that just tell you time since last boot? I think Glyn was looking for "time since power applied" to try and sync emonHub starting with the AVR's setup() routine. Although this method would work it would also slow down every reboot unnecessarily and I think this approach is a bit flawed as if a either devices "setup" routines timing alters or if a watchdog, manual reset or sketch upload restarts the AVR's setup routine, emonhub could try and get a response when the AVR isn't able to provide one.
I don't mind adding a delay but shifting the hole along the timeline doesn't remove the hole and it's only a matter of time before it causes a problem (probably a weird, random and apparently untraceable issue that we don't connect to this!)
Paul
Re: Delay emonhub startup on cold boot?
Couldn't the emonPi send a 'delay' (or 'wait') response to emonhub during this initial startup period? Or is it completely unresponsive on the serial (why)?
Jörg.
Re: Delay emonhub startup on cold boot?
Thanks for replies guys. Reading your replies made me question why exactly the 10s delay is needed, the conclusion was it's only needed on the emonTx V3 since residual charge in the reservoir capacitor in the AC-DC power supply circuit could cause an AC waveform to be falsely detected if an AC input has just been unplugged, hence the 10's delay. Since the emonPi does not power itself from AC there is no need for this delay at all = problem fixed!
Yes I am using auto baud detect to detect 38400 which is used by the emonPi.
Good spot regarding using 'v' to change AC-AC calibration for EU or US. This is indeed used by RF12 Demo to return version. I will change to using 'p'
"Available commands:\n"
" <nn> i - set node IDs (standard node ids are 1..30)\n"
" <n> b - set MHz band (4 = 433, 8 = 868, 9 = 915)\n"
" <nnn> g - set network group (RFM12 only allows 212, 0 = any)\n"
" <n> c - set collect mode (advanced, normally 0)\n"
" ...,<nn> a - send data packet to node <nn>, request ack\n"
" ...,<nn> s - send data packet to node <nn>, no ack\n"
" ...,<n> p - Set AC Adapter Vcal 1p = UK, 2p = USA\n"
" v - Show firmware version\n"
;
On another unrelated topic do you see an issue using long or unsigned long as struct variables? I seem to have issue with emonHub posting an empty variable as well as the correct one when using long / unsigned long for pulse count
Re: Delay emonhub startup on cold boot?
That's excellent, although I do now wonder whether even the shorter sleep periods in any of the sketches could cause an issue. currently the time emonHub waits for a response is quite short, if this does clash with a sleep period it may not get a response before moving on (or results in an error) .
There shouldn't be any issue using a long datatype as a struct variable as long as have defined that in the nodes datacodes,in the conf, as emonHub would perceive the 4 extra bytes of an additional long to be 2 integers unless told otherwise.
Paul
Re: Delay emonhub startup on cold boot?
Hi,
I am facing the same problem.
I have configured emonhub to automatically start when my raspberry pi boots up, but when I reboot my raspberry I get following warning in my emonhub log file and emonhub is also not receiving or forwarding anything.
I managed to fix this problem by stopping the emonhub service, wait some time (20 seconds) (not sure if this waiting is needed) and start the emonhub service again.
In that case the emonhub log file doesn't contain the warning message (see below) and was receiving the data from emonTx and emonTh and forwarding it properly to emoncms.org
Of course next time my raspberry pi reboots I will have the same problem and need to apply the same manual steps to get it fixed. Is there any solution I can apply that will work automatically also when my pi reboots ?
kr
jan
Re: Delay emonhub startup on cold boot?
If you define the "com_baud = " value in emonhub.conf it will not run the baud detection which is where the issue is being picked up, from a cold boot (power cycle) due to the rfm2pi being reset, a normal "soft" reboot should be ok. But if you know your baud, it is always best to define it if you can.
Paul