Malloc Array Airgradient ESP home Repository

Software integrations
#21

I really want to try to only have one main config for every AG device. Maybe your solution is on to something because I can filter out non valid measures etc. The drawback is that if I want to include many more sensors they all need to be included and will collide proabably.

I tried with setting up fake template sensors which can be replaced with the real sensor but that also generates errors I cannot fix. If only esphome would support a function like id(sensor).exists().

I have no real knowledge about cpp so maybe there is a way to check for an object without using that objectname which causes an error by the compiler. Also tried a pointer from that id, which works, but then again using the real id in after the IF clause gives a compiler error.

The really big workaround is defining a display lambda for a set of sensors which are included together. It works but its not really flexible anymore.

#22

With the differences in esp chip models, plus different displays (or no display) I donā€™t think a single config across all models is possible, but with packages shared between those that are common, the difference in the main files can be greatly reduced.

#23

This sort of question comes up fairly often in the ESPHome Discord, and the answer is no, you canā€™t do it. ESPHome requires the IDs of all referenced components to be known at compile time, and doesnā€™t support any form of conditional compilation.

As a result your display lambda has to be written for exactly the set of sensors you want to display, it canā€™t adapt itself to the sensors available in the configuration. Doing something like that would require a preprocessor of some sort which accepted the inputs to tell it what to include and which then wrote the YAML config for ESPHome to compile.

#24

I just pushed a significant change to the main branch that now uses packages to keep relevant ESPHome items together, and changed them to reference the github repo by default, so all you need is the top level file for a particular file and it will pull down the rest.

There are instructions in the README to make this all local if you donā€™t want it referencing an external repo.

New buttons, new features, new pages, new breaking changes!

2 Likes
#25

That looks very nice!

#26

Has anyone else had the experience of frequent reboots with this device? Hereā€™s a screenshot of the uptime sensor over the last 24 hours:
image
I uploaded some new firmware a few times at the red X, but then the device clearly rebooted multiple times overnight. Iā€™ve tried setting both the api and wifi options for reboot_timeout to 0s (to disable the reboot) but that clearly didnā€™t help. Is the the GPIO2 watchdog to blame for these reboots? Or is there another option I need to change?

Edit: The Home Assistant log shows this error when the reboot happens, so it must be the AG One device triggering a reset for some reason:

airgradient-one-12f004 @ xxx.xxx.xx.xx: Connection error occurred: [Errno 104] Connection reset by peer
#27

I certainly have multiple reboots on mine as well, although I suspect it is related to my Unifi wireless access points, but havenā€™t proven it just yet.

Probably best to at least make a new thread here about ESPHome and reboots, or maybe better to do it on my Github repo and we can track it there.

When I first got my AirGradient ONE I was seeing pretty regular reboots with the Arduino code as well, so may not be specific to ESPHome, but lots of unknowns, but Iā€™ve heard mention from other users as well.

#28

I have one currently at ~219 hours of uptime, and another which rebooted earlier today for unknown reasons.

#29

In general we see extremely high uptimes but the external hw watchdog needs to be triggered to avoid reboots. I would say at least every 4 minutes to be on the safe side.

#30

Since 7 AM this morning, itā€™s rebooted 8 times. I added the ESPHome reset reason text sensor yesterday and it looks like the watchdog timeout triggered it every time, despite the watchdog set to 2.5 min intervals. I havenā€™t tried messing with the watchdog output length, e.g. longer than 20ms, but I wonder if that would help. Anecdotally, it also seems like the reboots happen more frequently when firmware is uploaded via WiFi vs a wired USB, but I havenā€™t explicitly tested that, either.

image
image2481Ɨ1137 215 KB

#31

I have a feeling that the mention of a watchdog is an ESPHome related watchdog and not the hardware watchdog on the V9 board. Iā€™m getting reboots on the v4.2 board that doesnā€™t have a hardware watchdog, although I havenā€™t setup a reset reason sensor, Iā€™ll have to look into that.

I have an open issue from way back before the ESP32 chip was used
pmsx003, D1 mini (esp8266) and debug logging causes reboots Ā· Issue #4233 Ā· esphome/issues (github.com)

A suggestion was to get the logs while plugged into the ESPHome server so could get the decoded stack trace

Can you get serial logs from the crash, preferably with a decoded stack trace, which requires it being plugged into the device running esphome (not over web serial)?

The v9 board this wonā€™t work with since the UART is in use that would send logs out the USB port. The INFO logs are so chatty on other that I canā€™t catch the moment it reboots, so I probably need to change the logger settings so it doesnā€™t send all of the INFO levels so I can only see a crash.

#32

What is strange on your reboots is the irregularity. If it would be the hw watchdog I would expect a reboot after exactly the same time intervals.

I wonder if some other reasons here. Can you try and disconnect the sensors and use a different power supply and check if that has an impact?

#33

Right now Iā€™m looking at this Issue related to http_request taking too long causing a reboot for some users
Crash on http_request.post Ā· Issue #2853 Ā· esphome/issues (github.com)

Since that is being used to report to AirGradient, it could be related. Iā€™m setting up the reset_reason sensor and getting one of my Pro v4.2 setup to connect directly to the ESPHome server to get the decoded stack and see if I can recreate.

I could also try turning off upload on a device and see if the uptime changes, which would either lend credibility to this theory or not.

#34

I just posted a workaround for that problem in the issue, but Iā€™ll repeat it here (itā€™s only applicable if the ESPHome config is using ESP-IDF):

esp32:
  framework:
    sdkconfig_options:
      CONFIG_ESP_TASK_WDT_TIMEOUT_S: "15"
1 Like
#35

I considered trying the ESP-IDF framework this week to see if that helped with the reboots, but when I try to switch from the Arduino framework, I get this error message when I validate the yaml:

http_request: [source <unicode string>:54]
  
  This feature is incompatible with esp-idf.
  {}

The contents of line 54 are just the top-level http_request: and some comments:
image

Are you using the ESP-IDF framework with the http_request feature?

1 Like
#36

n=1 here, but after reading your comment, I also turned off the ā€œUpload to AirGradientā€ switch for testing, and my device did not reboot at all overnight. Given my deviceā€™s previous instability, this seems promising for debugging.

#37

Can you PM me your serial number of the monitor? Then we can check on our server if there were time out issues with the requests.

#38

Ahh, sorry, I started using the ESP-IDF flavor of http_request from an open PR so long ago Iā€™d forgotten about it!

#39

My device has had 100% uptime, no reboots, since turning off the ā€œUpload to AirGradientā€ switch. Given the previous instability, this seems definitive enough for me. My main use case is Home Assistant anyway, so if AG doesnā€™t use the data from my sensor (and I donā€™t know why they would), then uploading it to AG is unnecessary.

#40

For the indoor monitor we donā€™t need any user data. For the outdoor monitor it would be nice if you share your data with us and make your outdoor monitor public. Then your data is shared with openAQ and available for research etc.

1 Like