Aldi CasaLux V1 + usage_tracker = weird totals for me

[MnM001]

Hi,

I have noticed that you have managed to get the usage_tracker going for the Aldi rgbw (v1) led lights.

I have been trying to incorporate that into my yaml too but I get some weird issues.

The first time I turn the light on (or after a reboot or flash of new esphome firmware as my light is set to turn on automatically at start) duration for last use initially shows N/A until I turn if off ). When I turn it off it fills the time with 489712.500 h. That carries over to the duration lifetime use.
This issue happens every time I reboot the light or cut power to it.

After I turn it off for the second time, duration last use starts showing the real time it was on for and I think it also adds it correctly to the duration lifetime use but by this time the damage is already done as duration lifetime use is already wrong (the 489712.500 h initial hours are already there)

Each time I reboot the light (for whatever reason) the cycle starts again and every reboot it adds another 489712.500 h to the total.

If you have any idea on how to sort this that will be great.

Cheers.

[MnM001]

I managed to figure something around the cause but could not find a fix yet.

I seems to be a time issue. The hours mentioned before (489712.500) if converted to years and subtracted from 2025 it results in epoch time (1/1/1970).

So while I have a ntp server and configuration in my yaml file, it seems that the components for usage_tracker is starts before that. I need to figure a way to slow down the start of usage_tracker until the ntp time is synched. Tried a few things but nothing worked.

If you have any ideas (maybe it can be done in your custom components files??) please do let me know.

[Roving-Ronin]

I'd say it needs a change in the component, as that appears to be related to it processing before (as you say) the SNTP updates.

I'm flat out atm, but if you want to fork and see about updating and then submit a pull, please do.
I'd suggest looking at L63 - L70 of one of the gas statistics, we I had to add a delay into the setup (for SNTP updating) before it then went on to processing the data. That issue saw the previous saved data being wiped on flashing updates and and resolved by this.

See:

myHomeAssistant/components/gas_statistics_mj/gas_statistics_mj.cpp

Line 63 in 0fc7a80

// Delay processing until SNTP sync

[MnM001]

Hi - thanks for getting back to me and your suggestions. Unfortunately I don't have any coding skills so I cant attempt what you suggested :( - I will patiently wait until you have some time to look and fix this.

[Roving-Ronin]

You assume that I have coding skills ;-) LoL

[MnM001]

LOL - at least you seem to know what you are doing ..unlike me :)

[MnM001]

I managed to make it work with (perhaps newer) components of ESPhome (so I don't usage_tracker at all this way). Also there is no dependency on NTP sync

Need a binary sensor:

binary_sensor:
  - platform: template
    name: "Downlight State"
    id: downlight_state
    lambda: |-
      return id(${device_id}).current_values.is_on();
    internal: true

then define the duty_time sensors and its subcomponents:

sensor:
  - platform: duty_time
    id: my_light_duty_time
    unit_of_measurement: h
    accuracy_decimals: 3
    filters:
      - lambda: |-
          return x / 3600.0;
      - delta: 0.001
    sensor: downlight_state
    name: "Duration Lifetime Use"
    update_interval: 60s
    restore: true
    web_server:
      sorting_group_id: group_light_usage
      sorting_weight: 2
    last_time:
      name: Duration Last Use
      unit_of_measurement: h
      accuracy_decimals: 3
      filters:
        - lambda: |-
            return x / 3600.0;
        - delta: 0.001
      web_server:
        sorting_group_id: group_light_usage
        sorting_weight: 1

It works perfect for me. However I am not sure if you are going to miss on anything if you do it this way too.

[Roving-Ronin]

That looks good and saves having to use a custom component, but does it save the value between reboots / re-powering the device, but especially between re-flashing with new ESPHome versions?

Trying to remember back a few years if I did the tracker, because other sensors like this would be wiped by updating ESPHome version to devices.

Please test and advise... if it stays, I'll probably just use the duty_time myself.

[MnM001]

Tested and it survives reboot, power off, firmware upgrades. Of course is governed by

preferences:
flash_write_interval: 5min

but I think yours was as well....

[MnM001]

I have a different question - I see that you are monitoring you gas and water with the A16 device.
I have already setup my water monitoring with the same device as you (A16) a long time ago but interested in the gas side of things.

What device did you attach to the gas pipe to enable monitoring?

[Roving-Ronin]

Simple $2 reed sensor, as the gas meter 'spinning dial' has a magnet in it, so just need to add a red sensor, determine what volume each rotation of the last dial equates too (mine is 0.00m3 so one turn is 10L).

I have to re-do my water and gas sensors, taking my not account this new integration. You might be interested in it also.

https://github.com/markaggar/Water-Monitor

[MnM001]

Thanks for the information.

That water monitor blue print looks interesting. Will give it a try.

[Roving-Ronin]

Tested and it survives reboot, power off, firmware upgrades. Of course is governed by

preferences: flash_write_interval: 5min

but I think yours was as well....

In v1.3.0 I've removed the custom_component and replaced with the duty_tracker, iirc originally ended up using the component as the duty_tracker didn't work, so comes full circle now ;-)