No setting informations in Home Assistant

[DennisXK]

Hello, I have successfully updated my Awtrix 2 to Awtrix 3. It is running on an ESP32 with 30 pins. Everything works fine so far, and it also integrates with Home Assistant (custom apps). However, I noticed that this Awtrix does not show any system information (sensors) – for example, IP address, free RAM, etc.

On the flashed Ulanzi displays, I do get these sensor data displayed in Home Assistant.

[Nepomuq]

Same here. I have two DIY Awtrix and another pair flashed Ulanzi Clocks. Of the two diy Clocks one has an SHT-31 Sensor connected. Just the one with a Sensor has the Bug. I tried reflashing it. The Firmeware Version is 0.98.

What i found out so far is: If I set the "sensor_reading = false" in the dev.json every Info exept Humidity & Temp are published via MQTT. If the Sensor is activ (sensor_reading = true) , there is no "[PREFIX]/stats" MQTT-Broadcast from the Clock anymore. On REST-API and Native Apps the Sensor Data is visible and correct.

I tried to trace the bug in the source (PeripheryManager.cpp). The State Broadcast is only triggered in line 749-753:

if ((currentMillis_Stats - previousMillis_Stats >= STATS_INTERVAL) && (SENSORS_STABLE))
    {
        previousMillis_Stats = currentMillis_Stats;
        sendStats();
    }

The first part is simple the "timer" but the &&(SENSORS_STABLE) could be the problem. It must be 'true' but is only set so when there is no Sensor present. All other cases which set it to "true" are not triggered normaly?

The main takeaway is: Try "setting sensor_reading" = false in the dev.json and it may work a little :-)

[Nepomuq]

Hello again, i fixed the issue for me. As suspected in my post yesterday the state broadcast is skipped because the SENSORS_STABLE variable is always false. I recompiled the firmware with only one little change and now everything works fine. That includes the Sensor Data as part of the MQTT State Broadcast to HA. Here are my Steps if anyone wishes to repeat this fix. But keep in mind that in the end i don't really understand the whole code and a real sollution has to be implemented by the developer Team into a future version.

Short Version: Add "SENSORS_STABLE = true;" to the PeripheryManager.cpp Source File at Line 525. Then recompile the firmeware, install it and it's fixed.

Step by Step on MacOs (should be the same on Linux and Windows):

1. Install GIT and Python3 (there are guides everywhere so i won't go into details)
2. Install PlattfomIO Tools with python3 -m pip install platformio in the Terminal
3. Pull the Repository and enter the folder with: git clone https://github.com/Blueforcer/awtrix3 cd awtrix3
4. Open /awtrix3/src/PeripheryManager.cpp in a texteditor of your choice and look for the following Lines (around Line 525):

            CURRENT_TEMP += TEMP_OFFSET;
            CURRENT_HUM += HUM_OFFSET;

add SENSORS_STABLE = true; in a new line above CURRENT_TEMP += TEMP_OFFSET; and save the file 6. run pio run -e ulanzi in the awtrix3 folder to compile the new firmware. If you have an upgraded Clock (Awtrix2 to Awtrix3) maybe its pio run -e awtrix2_upgradebut i just tried the ulanzi version. 7. go to /awtrix3/.pio/build/ulanzi and find the file "firmware.bin". The .pio folder is hidden inside the Awtrixso you may just search for it) 8. Open the Webinterface of your Awtrix Clock and select "Update" in the Top Menu. Select your just created firmware.bin file under Firmware. Leave the Stuff under "Filesystem" untouched and click the "Update Firmware" Button. The clock should now install the changed firmware and reboot. 9. Enjoy Sensor Data :-)

Again: Just because that worked for me and fixed my Awtrix it doesn't have to be the same in your case. Hope that helps :-) and thanks to the Developer Team for the awesome Awtrix Stuff.

[DennisXK]

Great that you found the cause. I think blueForcer should release an update to fix the problem.

@Nepomuq can you publish the firmware.bin file? Thanks

[Nepomuq]

Here are the firmeware files for ulanzi (that i use for my DIY Clock) and the awtrix2_upgrade Version that may be the right one if you upgraded. Consider this stuff unstable. If you want to have it fixed right now, try it. If you want to be sure that nothing goes wrong, wait for an official patch. Awtrix-Firmware.zip

[luebbe]

@Nepomuq , your fix doesn't make sense to me, because you set it to true in any case, making it useless. The "SENSORS_STABLE" was introduced in order to prevent the first, totally chaotic, battery ADC values from being sent to home assistant. So there are two cases (look at the #ifndef awtrix2_upgrade in line 487)

1. you have a battery: SENSORS_STABLE becomes true, when the ADC values are in a sensible range for the first time.
2. you don't have a battery: SENSORS_STABLE is always true.

To me that sounds like the condition if ((ADCVALUE > 100) && (ADCVALUE < 1000)) is never met on your clock. Could you please check that? If I understand the ifdef correctly, you should #define awtrix2_upgrade if you don't have a battery, but I don't know what else will be disabled when that #define exists without looking at the rest of the code.

With regard to that, SENSORS_STABLE = true in line 531 doesn't make sense at all.

[Nepomuq]

You are right, my DIY Clock has no battery build in. It could therefore be the real cause of the problem. My fix to insert the "SENSORS_STABLE = true" came to mind when i saw that in the following code there is "if (sensor stuff) {} else {SENSORS_STABLE = true"}. As i wrote in my first response, all other places where SENSORS_STABLE is set to true seemed not related and would not trigger. I totaly agree with your opinon that my fix is making SENSORS_STABLE useless. But i'd argue it was already useless before for my device and now it's behaves like it should've form the start.

This is the part i'm writing about:

if (SENSOR_READING)
        {
            switch (TEMP_SENSOR_TYPE)
            {
            case TEMP_SENSOR_TYPE_BME280:
                CURRENT_TEMP = bme280.readTemperature();
                CURRENT_HUM = bme280.readHumidity();
                break;
            case TEMP_SENSOR_TYPE_BMP280:
                CURRENT_TEMP = bmp280.readTemperature();
                CURRENT_HUM = 0;
                break;
            case TEMP_SENSOR_TYPE_HTU21DF:
                CURRENT_TEMP = htu21df.readTemperature();
                CURRENT_HUM = htu21df.readHumidity();
                break;
            case TEMP_SENSOR_TYPE_SHT31:
                sht31.readBoth(&CURRENT_TEMP, &CURRENT_HUM);
                break;
            default:
                CURRENT_TEMP = 0;
                CURRENT_HUM = 0;
                break;
            }

            CURRENT_TEMP += TEMP_OFFSET;
            CURRENT_HUM += HUM_OFFSET;
        }
        else
        {
            SENSORS_STABLE = true;
        }

Based on this my solution was to set SENSORS_STABLE to true in the other/every case. You are right to say, that the position i inserted the code is quite random. I'd like to learn more about your sugestion to use #define awtrix2_upgrade. Is there some documentation somewhere about that?

[luebbe]

The only documentation for #define awtrix2_upgrade is in the code, I fear :) and it its used in a lot of places. But maybe we should take a closer look if there is a define or condition that allows us to detect whether a battery is built in. Do you have something like that in your configuration? In that case it would be better to change the ifndef awtrix2_upgrade to a different condition. I guess the proper way to go will be a separate define like has_battery which is set to true/false depending on the environment.

[Nepomuq]

I find it a bit strange that the Sensor part contains SENSORS_STABLE at all. In my case, as you pointed out that left me confused. For me it seems like, SENSORS_STABLE is only for things related to the battery. So why is it changed in case there is no Sensor but left untouched if there's a Sensor. This was the frist time i messed with the source code at all. So everything else, including the Battery detection is unchanged in the binarys i posted.

Your Idea to have an switch to turn the battery stuff completly is good. I guess almost every DIY clock is build without a battery and many Ulanci owners remove the battery. If there wasn't the chance to leave marks on the case i would remove the battery from my Ulanci Clocks as well.

For now, as i wrote before, all this is just a Workaround until there is a better solution by the devs.

[DennisXK]

@Nepomuq Removing the battery without leaving traces is no problem 😉. Once the battery has been removed and the charge controller has been short-circuited, Home Assistant shows 0%.

[luebbe]

I just createt a PR that attempts to solve the problem. In order to make it work on your side, you have to undefine BATTERY_PIN when your device doesn't have a battery.

[Nepomuq]

Thank you. Glad it's fixed in a better way than i did in the next Version.