Ok, so I had forgotten my girlfriends complaints. Seems my gf’s bedroom light turns on by itself. Today I asked her to help me by keeping a log of the exact time it happens. It doesn’t do it all the time, in fact it seems to only do it once a day, but around 3am. She says last week it did it two nights in a row then it didn’t do it again until last night.
Well seems she doesn’t really have to keep a log, since I just noticed I can view the exact time it happens via history or via logbook. By taking a closer look at the logbook it seems that specific tasmota everynight at 3AM “Sol changed to unavailable” How can I troubleshoot why it is doing that? Since it does it at 3am everynight, seems to be something “scheduled”. Also I think it is tied up to HA since the HA was unplugged for 4 days, and it seems those are the days that it didn’t do it.
Switch is not configured via yaml file, doing the autofind option.
I don’t know how to check the MQTT broker’s log. Will research how to do that after I post this.
I did take a closer look at the regular HA log, and noticed there are two tasmotas (my gf’s room and her daughters room) and it seems both of them right at 3am everynight go onto “changed to unavailable”
It will be because you have/had retain: true set in config at one time or another so it will switch on every time it reconnects to the broker. Fun eh?
It is fixable. Easiest way I have done this is to delete the broker and restart home assistant and then add the broker again and restart again. This deletes the mosquitto persistence database and will fix it. You can also send a null packet to the device but it never seemed to work for me.
This is also why it’s great when the mosquitto addon is just using the defaults.
David if you ever come visit Cancun I would be happy to hook you up with an awesome tour!
I haven’t followed your suggestion yet, but I am pretty confident that is the issue, as the two tasmotas that have the issues are the two I originally tried to set up manually, and I was using retain:true on them.
By deleting the broker, you mean click the trash can on the mqtt integration screen, then reboot, then do the mqtt integration again?
Now, why does it drop at 3am everynight? Is that something HA is set up to do? I find it odd that it does it exactly at 3am but I don’t have any scripts or anything scheduled.
As for the mqtt log. On the mqtt add on page I do see a log, but it is not a full log, and it doesn’t seem to have any time stamps. This is snip of what I get
1549683808: Saving in-memory database to /data/mosquitto.db.
1549683821: Client DVES_553CF2F2 has exceeded timeout, disconnecting.
1549683821: Socket error on client DVES_553CF2F2, disconnecting.
1549683823: New connection from 10.0.0.240 on port 1883.
[INFO] found mqttuser on local database
1549683823: New client connected from 10.0.0.240 as DVES_553CF2F2 (c1, k10, u'mqttuser').
1549685609: Saving in-memory database to /data/mosquitto.db.
No you’re confusing the broker with the Integration.
I am talking about deleting the broker - ie removing the add-on and then restarting, adding it back and restarting again. It’s the easiest way to clear the dross out of the broker.
The time stamps will be the seconds since some event… 3AM might be when your wifi powers down or something like that? Dunno… but if you get rid of the persistence flag you won’t need to be concerned about it again.
Ok I wasn’t sure, so I just deleted the integration, and I was about to delete the “add on”, so I was in the right track.
If I am understanding correctly, by deleting and adding again I am getting ride of the reatain:ture part, but does that mean that everynight a 3am they will “changed to unavailable” except it won’t change the state of the switch when it does it? Why only those two tasmotas change to unavailable at 3am?
I will confirm tomorrow, but I think her daughters tasmota connects to the main router downstairs, and my gfs connect to a second router on her room, and as far as I know none of the routers are set up to reboot by themselves.
yes you will get rid of the retention flag. They may still go unavailable briefly but at least when they reconnect they won’t flash.
you should be able to see in the logbook for the switch (in Home Assistant) when all the connect/reconnects occur…
I highly recommend you try MQTT Explorer. It displays all the broker’s topics in a tree-view and, for your purposes, allows you to easily purge a retained message (just click the big red button). For trouble-shooting MQTT issues, this is a very handy tool.
David, yes that is the log I found and how I noticed that only TWO of the tasmotas go unavailable everynight at 3am. When I list all switches, I can see they all go unavailable at some times, but they do so at random times. But them two do it everynight at exactly 3am
Does your router go into a green mode? How long are they unavailable for? Are they only unavailable at that one time? Remember I said core 2.5.0 was a nightmare with disconnects (at lease the beta ones were)
All your issues could be related to either the firmware or the power as we discussed yesterday.
If you’re not … all topics are listed on the left in a tree-view. Expand the tree to show the topic that interests you. Click on the topic and all its details are shown on the right.
The Value section shows the message’s contents (and if it’s retained, the QOS, time received, etc).
The topic’s messages (as they change over time) appear in the History section.
The Publish section lets you publish a message to the selected topic. The message editor even validates JSON.
I haven’t paid attention to the router, will check tomorrow. It seems to only go unavailable for a few seconds based on the log. I understand that 2.5 has issues with disconnects, and on top of that I have power supplies with noise, but with the little that I know I am pretty sure both of those issues together don’t explain the 3am glitch, something has to be triggering the issue.
Will check her router tomorrow as perhaps by default it is set up to reboot at 3am and I just didn’t know about it.
