Machine times between reboots/lockups reducing

General
121

Typically not. Random corruption can happen for all sorts of reasons and is likely to only affect a few bytes out of the several GIGA-bytes on your computer. That code or data may only rarely be reached or the corruption may be to data that might still be understood - just wrong.

Only if the corruption was IN node. You have probably 100's of thousands of files and gigabytes of code and data on even a Pi.

That happens to most of us :grinning: I recommend firing up a test instance of Node-RED and using that for experiments. Keep a "live" instance running with just the things you really need.

122

Thanks.

Noted.

Anyway, things are a lot more quite than before, so that is good. 80% probable it is/was a power problem - so far based on things.

Though I would like to wait a couple of weeks just to be more sure.

123

Ok, 21 June. Not exactly sure when - oh hang on..... about 13:00 today:

Only for the sake of other things happening, I put the last of the three machines on an official power supply.

Let's see what happens.

But other things are happening. See other thread.

124

I spoke too soon.

Update:

Today - 25 Jun 2021 06:50

When I got up I saw that one of my wifi devices had been turned on.

So it kind of throws a brick through the window for the idea of "all is now fixed".

Observation:

It has been 3 weeks 5 days since I put a (the) machine onto an official power supply.
Which is pretty good all things considered.

The machine is question is a RasPi 2 b Rev 1.1
It also runs PiHole. Why do I mention this now? Hang on and I will explain/elaborate now.

Though slightly off topic I had fallen for this when I was setting up PiHole originally. (Way back)

The modem/router did the DHCP stuff originally.
This was good/bad for a whole set of reasons. Outside the scope.
But it became evident that the PiHole machine should do this and so it was set as the DHCP server.

About a week ago - for reasons now unknown - I put the router back as DHCP and took PiHole off.
Then I remembered why PiHole needs to be the server and promptly put it back.

Interestingly this caused the wifi device mentioned above to be turned on.
I'm not sure which side (part?) of it did it. The making the router or making PiHole the DHCP server.

Although this isn't a reboot, it is one of the problems noticed originally with machines either locking up or going crazy and needing to be power cycled.

125

You need to stay on track - you are veering off again (as you usually end up doing)

What does changing your DHCP server (PiHole/Router) have to do with CAUSING a device to turn on ?

Unless one of them is running as a PXE/WOL server and has a task set to wake this particular device - even so - this would make no difference if it was the DHCP server or not - as PXE/WOL is performed on MAC address not IP address.

I think you need to go back and read that post again and see how confusing it could be for someone outside your network ? Particularly introducing it at the end of a thread about troubleshooting PI reboot issues.

Are the PI reboot issues fixed now by moving to the proper power supplies ?

If so what is this mysterious WIFI device that has been powered on - would probably need its own thread rather than confusing this one further

Craig

126

I think that by changing the DNS it caused the WIFI devices to rebroadcast their LWT and so the LWT told the device to turn on.

I'm saying this because when the RasPi was the DNS if there were power problems, it would re-negotiate all WIFI devices and they would (probably) re-send their LWT.

So:
This was happening quite often originally. On non-standard power supply.

Putting it on the official one, things really settled down. No lock ups, no mysterious WIFI devices turning on.

So now for 3 weeks, 6 days 5 hours (at time of posting) things have been stable.

This recent thing with moving DNS from the Pi to the router and back only simulated what would/could happen if the DNS was the Pi and there was a power supply.

Would this concur?

127

How does a LWT force a device to start ?? Do you have a flow somewhere that does this ?

You do realise LWT is only to do with MQTT - so unless the devices are all running MQTT then they will not be sending out LWT i.e.a normal PI without Mosquitto and/or NR would not have anything to do with MQTT/LWT ?

Craig

128

Well, the device is a TASMOTA thing. I am still new to that.

But from what I understand if it receives a LWT it sets itself to that.

It is WiFI and connecting to the MQTT broker.

If the DHCP resets and its IP address is re-negotiated.... The LWT is sent. Or something like that.

It is controlled by MQTT. (Ok, I just said that 2 lines back)
LWT and MQTT are associated. MQTT has a LWT and birth certificates when dis/connecting.

So (from a long time ago):
All things would be good. I would go away.

I would come back and the WiFi device (controlled by MQTT) would be not as left.

I would reset it to what it should be and just continue. (Silly me, but I am dumb. That's a given)

The other day when I was playing with who was the DHCP server, I took it from the RasPi and made it the router.

Then I remembered WHY it was on the Pi: it is also running PiHole.
If the router is doing DHCP, it is a bit difficult to know which device connected via DHCP is doing what.

So I put it back to the Pi.
Shortly there after I noticed the device afore mentioned had been set to how I was finding it after being away.

Though not conclusive: If the DHCP was somehow reset while I was away, it would explain why said device was not as I left it.

So this kind of re-enforces the power supply suspicion to causing problems.

Clearer?
It is difficult for me to remember what I have said; what I haven't and what is and not needed to be told.

Yes, I need work. Who doesn't?

129

What does that mean?

130

You missed the "from what I understand" part.

From what I understand (deja vous) and have seen: when a WiFi device connects, it sends a LWT.

In Tasmota that contains what the device is supposed to be set at.
Yes, I can change the config of the device, but that is then reflected in the LWT.

So if the LWT is sent - because the DHCP server reset - the device is set to the default condition. Which is NOT how I left it.

However: You seem intent on disproving this.
I am reporting what I saw happen and what I did just before that.

So if it wasn't a faulty (for want of a better definition) power supply making the RasPi's DHCP reset / glitch every now and then, and AFTER I put it on a REAL supply and it was behaving itself more than it was........

I'm open to what else is wrong.
I want this/these problems to stop. Kinda difficult to move forward if everything I post is said to be wrong.

131

No I didn't. Virtually anything we write will be from what we each understand, what else could it be?

What sends an LWT to what?

What aspect of the device settings do you mean?

132

When your (Tasmota) device connects to the MQTT broker it can use LWT to tell the broker ā€œPlease post this message, to this topic, if you happen to notice that Iā€™ve dropped off the radarā€

Itā€™s a bit like telling your solicitor ā€œPlease post this envelope to the New York times if youā€™ve not heard from me in 48 hoursā€ :grinning:

I use an LWT topic called ā€˜statusā€™ and tell Mosquitto to post ā€˜deadā€™ to that topic if the device goes offline.
Once this LWT instruction has been given to Mosquitto then the device posts an ā€˜aliveā€™ message to the ā€˜statusā€™ topic.

It takes around 20 seconds for Mosquitto to recognise that the device has gone AWOL (you can change this in the Mosquitto configuration) and at that point it posts the ā€˜deadā€™ message to the ā€˜statusā€™ topic.

Looking at the ā€˜statusā€™ topic for that device tells me whether itā€™s alive or dead (or at least that it was alive 20 seconds ago).

So, itā€™s not a case of the device sending the LWT after it disconnects (which would be impossible), itā€™s the device saying in advance to the broker ā€œIn the event that you canā€™t reach me, please do thisā€¦ā€

Pete.

133

So in a nutshell Andrew we are trying to say we can not see how LWT can have any effect on the problem you have had.

When you flip flopped between DHCP servers - dependant on config of each of them - they may well have given different IP addresses to each of your devices, and then dependant on the config of your mosquitto broker they may have seen this as devices disappearing but unless you have a flow somewhere that is looking at the LWT from the broker and then performing specific actions based upon its state i think this may be a red herring.

Craig

134

OK, maybe not the LWT, but the BIRTH CERTIFICATE.

I can say with confidence that when I power on a BULB (which isn't the device in question) I get messages which maybe a LWT and/or BIRTH CERTIFICATE.

Who published what: Dunno.

But - and this is based on past (18 or so months) things happening.

I would set the power board (Tasmota) to ALL OFF. One of the outlets is/was/is used to do things.

I would come back after 2 weeks and it was not as it was left.
This would also happen quite frequently for the 2 weeks I was at home.
The board would suddenly change to this wrong state/condition.

That is/was a problem on its own.

ITMT, the machines are/were locking up.

Power supply. That became the only thing not changed.

So, a couple of weeks back I powered down the RasPi.
It is running NR, and PiHole. PiHole was the DHCP server.

I then connected it to a name brand RasPi PSU. It was working and the power board was behaving itself.

Granted it is is only 4 weeks, but that is 2 cycles of what I did for the past 18 months.

NO PROBLEMS!

The other day for reasons outside the scope, I set the modem router as the DHCP server rather than PiHole.

Then I realised why PiHole needs to be the DHCP server. I put it back.

Though I can't say if it was both, but later as I walked past the power board, it had become taken the state I found it in after my trips away.

Given: It had been 3 weeks and it was behaving itself and only when I changed the DHCP server did it fail, makes me suspicious that when it re-negotiates its IP address that this problem happens....

SO?

If a bad power supply was doing that intermittently that would explain a lot.

Now it is the name brand PSU and it has been behaving itself for 3 weeks....

That is re-enforcing that is WAS the PSU causing the problems.

135

Thanks Peter.

I am still very much at the shallow end of the pool when it comes to Tasmota.

I was badly explaining my poor understanding of how things work.

But I do believe that when it negotiates an IP address the message/s are setup/sent and the device takes on the "default" status.

Though I can change that, it is more that it was fairly constantly change from what I told it to be to a wrong state.

So I am suspicious that it was re-negotiating the IP address and so resetting to the default state.

136

OK check out the Tasmota console commands - you can setup a remote logging server in there.

Then force change the IP address of the power board - on your PiHole - reserve/remove the addess the power board has from the IP list and then reboot the power board.

See what messages it sends out to the logging server when it gets a new IP address - this might give you some ideas.

Having said all of that - i have a number of cheap power monitor (Kogan) plugs that have been flashed with tasmota - one of them has gone through 12,000 reboot cycles for no good reason - you may well find that your Tasmota is setup to restart the device if it loses IP connectivity

Craig

137

Thanks.

I'm not quite sure how that is going to work, but I'll try.

If it isn't connected to my WiFi - for what ever reason - how can it send data to the rsyslog?

I shall see if I can get my head around what you say. A lot of that is way beyond what I use/understand.

But I'll try.

138

This link goes a long way to explaining the problem.

I think I shall follow this thread first.

139

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.