Do you mean that if you add a chart set to display 6 hours, then change that to 3 hours, deploy it and then refresh you see the problem? Does it not recover if you restart node-red?
Correct, except that I deploy and check after every change.
It will recover but then break again some time later
PS, this guy:
Seems to been having the same issue, but he was trying to use much older data.. maybe this is related? im still trying to track down that undefined msg
I'll chip in here.
I had a theory, but when I saw this, it would seem I am wrong.
So, this caught my attention:
New theory:
(Actually you kind of answered it yourself and didn't realise.) (Post 14)
Somehow a value - in this case the Ohms - is undefined.
Earlier on in the flow when the values come in, you need a switch node that looks at the value it is getting and if it is NOT undefined then pass it on.
The undefined value could be the cause.
Another thing - just as I am saying - is the raspberry pi may be running out of memory too.
Fellas, I have found the problem. I will be posting a solution shortly.
Good to hear.
So, the clock starts at 00:00, which is the time Ive typically been working on this around.
I forgot that the Raspberry pi does not have a built in clock.
The problem is that I have this device setup as an access point so it can be used in the field, and the
Pi Zero W's wireless chip can only be set to transmit or receive, thus, NTP no longer works. After my many reboots and one shutdown, the clock was completely out of sync. When connecting to the client, the right end of the x axis was adjusting to the client time, but data provided was interpreted as from over 12 hours before hand. The problem avato92 was having is the same issue.
For those of you that see this in the future, there are several solutions.
Ill be jumping straight to the adafruit DS3231, although there are other cheaper options.
My solution for the time being will be to ssh into the pi with my phone or laptop on startup and set the time and date manually, although this is not required considering the primary function of the main device is to light up the neopixels based on the VOC value. My second device with the bme280 will be staying at an outdoor location with constant power and internet access, so no need to worry about it as the device checks NTP during startup.
Another solution that I plan to implement in the future is a second wifi radio (microusb<usba) set to connect to either a frequented access point (It will pass though and share the connection to clients) or to my phone's access point, however this comes at the cost of space and power, so Im on the fence about that one.
As for that one message;
5/13/2021, 9:15:18 PMnode: 72618df0.784504
msg : error
"TypeError: Cannot read property 'toString' of undefined"
This turned out to be the neopixel node accepting the number value of the msg.payload but not the topic.
Also, Resource usage is 0-10% CPU and 5-15% RAM. CPU/power usage can and will be reduced.
Thanks everyone for your help. I have learned a lot.
1 Like
Good to hear you found the cause.
Well done.
With the RTC the problem of having to SSH into the Pi should not exist any more.
Given you accept any drift in its time.
1 Like
Well worked out! I should have thought of the possibility of problems with the clock.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
