update Illuminance at least every 60 seconds, even if value not changed

[LaneaLucy]

i want to use a statistic sensor over the illuminance value to give me the minimal value of the last 15 minutes, but because the sensor don't update the value if it isn't changing, the statistic sensor runs out of samples and get unavailable. this commit should fix it by sending a value at least every 60 seconds, even when the value doesn't changed and therefore create a sample inside home assistant every 60 seconds.

[screekworkshop]

Thanks, I will test it. The current mechanism could indeed result in no data being pushed for a long time.

[LaneaLucy]

No data being pushed until the value changes

[LaneaLucy]

I'm actively using the changed code right now and I have max uptime since the change of 36.699 seconds

[LaneaLucy]

I don't know what the reboot caused but reset reason is "Software Reset Digital Core"

[screekworkshop]

I don't know what the reboot caused but reset reason is "Software Reset Digital Core"

It can be a combination of several things, usually the most likely being ESPHOME's default protection mechanism, which reboots the device if it can't connect to the WIFI or AP for 10 minutes.

[screekworkshop]

Situations such as WIFI channels and a multitude of devices lead to WIFI situations that can be very complicated and lead to various situations such as dropped calls and so on. This usually happens.

A usually useful tip is to set the router to automatically reboot at say 3pm every night, after which the more modern routers will re-select the channel and take care of those devices that were first connected to the WIFI.

But in general, even an occasional reboot will not affect the work too much, because reboots can often happen very quickly and the radar module always works independently.

This is probably a shame about WIFI sensors, there are so many devices using WIFI that the channel can be crowded, and small devices with PCB antennas have poor advantages

[LaneaLucy]

But for this to happen, the connection must drop for 10 minutes and the logbook says the connection dropped only for 1 second, so this would indicate a reboot while connected and 26 seconds before the lost connection, I still got state changes

[LaneaLucy]

Rssi is -44 dBm, so good connection, minimum is -48 dBm which is still very good. WiFi channel is fixed, so this can't be a problem too. WiFi devices are only 7, so this shouldn't be a problem too and the router runs openwrt which indicates no problem in logs and 4/4 connection strength. So I don't think it's a WiFi problem

EDIT: and another esphome device that sits under 0,5 m away, don't have the same problem and this has only -76 dBm, so if it's a WiFi problem, this device should have the problem, not the 2A sensor

[LaneaLucy]

Btw, just a reminder to push a new beta release to your website and Reddit ☺️

[SLboat]

Rssi is -44 dBm, so good connection, minimum is -48 dBm which is still very good. WiFi channel is fixed, so this can't be a problem too. WiFi devices are only 7, so this shouldn't be a problem too and the router runs openwrt which indicates no problem in logs and 4/4 connection strength. So I don't think it's a WiFi problem

EDIT: and another esphome device that sits under 0,5 m away, don't have the same problem and this has only -76 dBm, so if it's a WiFi problem, this device should have the problem, not the 2A sensor

There are a lot of possible factors to it, the ones I mentioned are some possibilities, and there are others that could just be something going on at the network layer and so on that then caused a reboot, which could also be some issue with the ESPHome part of the code.
It's strange, but as we have had the chance to test very many sensors (based on C3 or esp32, or esp8266) some basic conclusions are that this reboot probability can be improved if the router is rebooted periodically, but it's still unavoidable.

May just have to live with them, fortunately they are all very short intervals.

[SLboat]

With a family member in the hospital recently and very little time outside of work, it has been difficult to further elaborate on our findings over the past two days, unfortunately.
But overall, the 2A went with the C3 module from luatos, which is a pretty good choice of materials in every way.
It has some hardware advantages over the generally cheaper S2 and ESP32 (not in all cases of course).
For example, these are some of the sensors used in daily testing, using the luatos c3 module

[SLboat]

Throughout the overall situation, we found that the router had the biggest impact, and it wasn't just that the RSSI signal was great, it seemed like there was something unseen outside of the signal that was causing some sort of reboot to be possible.

[SLboat]

Another one of the earliest of our prototype products that ran for a very long time was also this luatos module:

[LaneaLucy]

I monitored it a little more, and I found out, that every unexpected reboot happens when the sensor detect motion. So maybe it could be a power spike? I still hadn't the luck to be at my laptop when the reboot happens to watch the log. Something like syslog for the esphome log would be very helpful, because I can't connect the sensor to my laptop, because the problem only happens, after long time no motion and my laptop is in a room with constant motion... So if you have something remote logging thing, that would be very helpful

[screekworkshop]

Yes, it's a good idea, but it gets very little information, sometimes it catches a kernel error message, sometimes not, and it's different for each device.

I think further if you need detailed debugging, you can use the jtag debugger to debug the source code of the pio project generated by esphome and do a deeper trace.

But I'm afraid that would get into the area of problems with some of the mechanisms of esphome itself, or with some parts of the driver.

The radar module may have some current interference, and a stable power supply would go a long way, especially regarding the ripple bit.

But every 2A is different, and every environment is different.

One of the toughest problems we had before was a small number of 1U S2 modules, s2 mini, which would cause shutdowns and deadlines if the operating temperature was too high. Later we reduced the operating frequency, and wifi strategy changed to power saving mode to alleviate this situation.

[LaneaLucy]

Jtag would be a bit overkill right now, because the usb uart logs kernel panic messages too. But like I said, it's not very practical for me right now without a small computer like a raspberry, connected to the 2A to get esphome logs and kernel logs. But then I need a galvanic isolation between them, because if it's a power problem, the filtering of the raspberry could fix the problem. The power supply I use for the 2A is a better one too. It's 5V 3A and it's shared with a second esp that controls a relay card. And yes, I know, I could have used the free pin's of the esp in the 2a and just add some config, but I hate soldering and the second esp has presoldered pins and I can just connect everything with Dupont wires. XD

CPU speed is reported with 160 MHz and temperature of the last 24 h max is 45,3°C with temperature going down after reboot before stabilizing again

[LaneaLucy]

Maybe you have the equipment to measure the amperage of a 2A with enough resolution and speed?