OK I have managed to upload yr original sketch. I now have 5 inputs but no data. bed time I was up at 4 pick up in the morning
See previous. Long red flash followed by many short red flashes on TH at power on. Not even updating. This with yr original sketch
Good morning.
See answers from last night.
Sketch modified as yr instructions compiled and uploaded.
Runs once then falls over. With 0.2 as internal temp zeros everywhere else
No more data transmits. Nothing on serial
Was this with line 126 changed? With the change, you should see some serial output:
emonTH
OpenEnergyMonitor.org
Node: 19 Freq: 868MHz Network: 210
and then, after a 2 s delay and if it has detected all the sensors:
Detected DHT22 temp & humidity sesnor
(with typo!) and
Detected 2 DS18B20
and DHT22 found.
And the LED is on while this happens, then it goes off.
This was as the sketch was initially sent and also after the mods.
Including the change to turn âdebugâ on in line 126? Did you save, compile and upload the sketch again after making the changes?
Did it compile without errors? (only warnings)?
Do you have your serial monitor set for 9600 baud?
OK saved compiled and uploaded. No warnings or errors
I get this on boot. Then no more. Long red led pulse then red flashing for a sec
Here are my alterations. No doubt something not right
Received in emonhub but then no more
No problem, my mistake converting the logic. (If Iâd got my emonTH V1.4 available, Iâd have been able to test it thoroughly.) Try this:
emonTH_markstjwebb.zip (4.8 KB)
Bingo. 5 sec updates as well. That will be fine as I am 5v powered. Thank you once again!
1 Like
Trystan has taken the 5 s option out of emonCMS, so if you want a nominal 10 s between reports to suit a 10 s emonCMS fixed interval timeseries feed, youâll need to trim the value of time_between_readings.
I canât calculate this accurately, because itâs what it says, and doesnât count the time to get the readings, and to get the reporting rate to something like 9.8 s, youâll need to set it to something like 7.5 s and then trim it.
Change line 318 to
Sleepy::loseSomeTime(time_between_readings);
and line 57 as a starting value to
const uint16_t time_between_readings = 7500; // time in milliseconds
and then adjust this either up or down so that values seen in the Arduino monitor come in with about 9.8 s between them. This way, you wonât get NULL values in the data.
No all is good. I have placed the TH in my loft doing what it should with a 5vdv supply. Another subject which maybe should be another thread.
This am when looking at my inputs there were 100+ phantom inputs from my usb?uart linked TX3. These seemed to have random titles and random values.
I duly deleted them.
As a result all the feed logs and calcs etc were removed from the valid inputs and no data is being logged and processed.
The feeds are still listed in the feed list but any record of where they were or the numerous calculations done with them have disappeared!
Any way of getting back?
That shouldnât have happened. Did you really mean you deleted ALL the inputs including the active, correct, wanted ones?
As far as I know, theyâre gone for good - however, @TrystanLea might be able to help.
Also, look at Unknown Nodes keep appearing
@TrystanLea This has all the hallmarks of another instance of trouble caused by autoconf
No I only deleted the rubbish inputs. Left all others of course.
The bottom one weirdly named âtestâ used to have a load of logging and associated calculations as well as 100+ seemingly random inputs. The 2 logs in test were me reinstating the feeds. Which I can do but all the calculation steps have gone.
These are the feeds
The feeds are still listed but the ones that went are not updating.
This I know little about - I think itâs all tied up with Trystanâs attempt to automate the generation of emonub.conf - and when it goes wrong, it goes wrong big time and causes a lot more trouble than itâs worth.
For the moment, if you have autoconf in emonhub.conf, turn it off ( = 0) and restart emonHub. But it appears even this doesnât always stop it. Keep an eye on the thread I linked to above.