Would it be possible to add Airgradient One as device like AirGradient-DIY | devices.esphome.io?
Or is that only a wiki? Would like to have something native like a component inside the esphome repo. This would enable OTA updates for both the components and configurations.
Are there drawbacks for this approach?
The content on devices.esphome.io are not ‘components’, they are example configurations.
it’s not possible to have something “in the ESPHome repo” which represents a full device with many components; the ESPHome repo doesn’t host YAML config files, but there are ways to write YAML configs which reference ‘base’ configs hosted in public locations.
It’s quite a bit of work to setup, and I’m sure that @MallocArray would appreciate some assistance after the initial conversion to packages has been completed but a good example of doing this is the esphome-ratgdo repository.
I updated my separate branch where I was testing the Includes and now am using Packages. I really like how it is coming together, although I still see some room for improvement in how I have it laid out, but it is working for all AG models (except the original Open Air)
MallocArray/airgradient_esphome at includes (github.com)
In this branch I also added the display page that another user created to match the Arduino code’s layout in the AG ONE model and I really like it, other than the fact it isn’t easy to read from across the room.
I also added Config switches to the config so you can enable any of the previous pages my configs had. By default it only shows the new single page, but you can enable or disable any of the pages so they are added to the rotation, including a blank page if you want to effectively disable the display.
Going to be looking at how that could be added to an automation to disable all of the other pages and enable only the Blank page overnight, but that is for the future
Looks like a version based off your config was merged in to the official esphome-devices repo. I opened a PR to fix a yaml error: Fix invalid AirGradient-One yaml by clarkminor · Pull Request #615 · esphome/esphome-devices · GitHub
However, it also looks like it was based off an older version of your code. From what I can tell, it removes the upload_airgradient component completely, changes some naming conventions, adds api/ota encryption, and enables the web server by default.
Is it worth trying to unify these two configs going forward?
Thanks for letting me know. I was still working on ironing out a few more things from my ToDo list before I was going to look into what it takes to get a device added to that page. At least it was acknowledged it was based on my repo. (Edit: As you mentioned, I have already added several improvements since the version they grabbed, so will want to update it at some point)
I’ll play around a bit more with the Packages, as I’m trying to decide if the Config button should be part of the Board package, or leave it standalone.
I also want to try out using the same Open Sans that the single page layout is using to limit how many fonts are included
Then there is revisiting the display and font on the AG Basic since it has a different OLED display that needs different layouts.
Once I get those figured out, I’ll update the main branch and then see about adding all of the 4 major models to the ESPHome-devices repo
It’s a good strategy to include just a fairly basic configuration into devices.esphome.io, but on those pages provide links to locations where more complete configurations (or even more updated configurations) can be found.
Do any of you @kpfleming @MallocArray found a way to only showing the sensors enabled on the display? For example I also have a pressure sensor on one device but not on the other. With the same display lambda I cant use it on both because that ID is not found. A simple if statement doesnt work because the ID is not fond. I did not find a workaround for this. Any tips welcome.
@Hendrik
I haven’t found a good way.
What if you still have the sensor for the pressure sensing device defined in the yaml even on the device that doesn’t physically have it? It will log errors since the device isn’t there, but then the config should still compile.
Might show ‘NaN’ for a value, but may be preferable to having to maintain 2 different configs
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.
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.
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.
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!
That looks very nice!
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:
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
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.
I have one currently at ~219 hours of uptime, and another which rebooted earlier today for unknown reasons.
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.
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.
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.
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?
