Preserve dali lamp configuration across restart

[AdamN1]

I think that dali lamp scan/full scan should happen only on the first run of the script. After lamp are found information should be saved to file. After restart dali2mqtt script should check if the lamp configuration file exist if so lamps should be fetch from file.

Benefits from the change:

1. we don't lose lamps after the restart, in my environment with conventional switch I need to manual switch all the lamps before starting dali2mqtt other wise lamps will be missing. If you have 10+ amps it's really annoying.
2. we can assign normal entity id, name like kitchen, bathroom etc.

After adding base support for storing lamp information we can use mqtt command to trigger lamp scan, search for new lamps, change configuration like entity_id, name etc.

[dgomes]

You have a conventional switch ? That is not a standard DALI setup, DALI controllers should always be powered on and lamps turned on/off through a DALI switch

But I can agree on having a persistent storage of DALI devices

[AdamN1]

You have a conventional switch ? That is not a standard DALI setup, DALI controllers should always be powered on and lamps turned on/off through a DALI switch

Yes, I have SSR switch that i use for switching lamps. Not all my lamps are DALI standard but all have SSR switch. I didn't know what lamps my wife will choose and if the manufacturer support DALI, so we have SSR switch on them.

I was thinking how can we support persistent configuration in device.yaml. I propose support for 3 different scenarios:

1. first fresh start dali2mqtt(default) we do full scan of devices on dali. For this we introduce variable scan with default value on
2. normal use, variable scan=on, dali lamps stored in device.yaml after start we scan lamps if we find lamp from device.yaml we send MQTT message with status on and settings, if we don't find lamp from device.yaml we send MQTT message with status=off. We can also intruduce new variable report_offline (default value on), if we have lamp i device.yaml and the lamp isn't found at the scan we send MQTT status=off. If variable report_offline=off and lamp X from device.yaml isn't found we don't send message(but support lamp)
3. normal use, variable scan=discard_offline, we discard lamps that are in device.yaml but not found in the initial dali scan.

@dgomes what you think?

[dgomes]

You should connect your SSR switches to a device like https://www.lunatone.com/en/product/dali-mc4l-din-rail/

If lights are disconnected (not just off, but without any means of controlling through DALI) then their state should be offline and not off

[AdamN1]

If lights are disconnected (not just off, but without any means of controlling through DALI) then their state should be offline and not off

you mean case 2, yes?

[dgomes]

my point is that we should:

1. always scan on dali2mqtt start
2. we don't find a previous lamp? we set that lamp to offline

No further case necessary, if the lamp is really removed you should just edit devices.yaml and remove the lamp (eventually we can create an MQTT command that does that for you)

[AdamN1]

When the lamp is in the offline state do we support topic for this lamp?

I see one problem with offline state. When we raport state=offline to HA entity will be disables and we will don't have posibility to change this from HA( maybe from automation ).

With state=off it's much easier, entity in HA is active so we can change state. In my scenerio were there is SSR switch and DALI dimmer I create group light for this two element and automation for brightness

Automation code

alias: Światło - Włączenie świateł - ustawienie jasności
description: Ustawienie poziomu jasności światła na podstawie zmiennej input_number.jasnosc
trigger:
  - platform: state
    entity_id: >-
      light.korytarz_ssr, light.kuchnia_stol_ssr, light.kuchnia_blat_ssr,
      light.kuchnia_sufit_ssr,
      light.salon_sufit_tv_ssr,light.salon_sufit_schody_ssr,
      light.lazienka_lustro_ssr, light.lazienka_wc_ssr, 
      light.biuro_sufit_ssr,light.biuro_biurko_ssr
    to: 'on'
condition: []
action:
  - delay:
      hours: 0
      minutes: 0
      seconds: 0
      milliseconds: 300
  - service: light.turn_on
    data:
      brightness: '{{ states(''input_number.jasnosc'') | int }}'
    target:
      entity_id: >-
        {{ trigger.entity_id | regex_replace(find='_ssr', replace='_dali',
        ignorecase=False)  }}
mode: single

I know that this is my home setup that i can change. I also agree that the best and simplest situation is when dali device is always connected but I think(didn't check) this isn't mandatory.

Dali support command 0x2D: "SET POWER ON LEVEL", so if there is a setting for power on I think that there is allowed to turn on/off power for dali device.

I don't think there is one right way to solve this, so let's give possibility to choose what should be reported via MQTT? (via variable)

[dgomes]

If the DALI device is powered off you cannot send any commands to it. In a DALI system devices are always connected (meaning they are powered) to the DALI bus and receiving commands even when the light is turned off.

Your use case is by no means a normal DALI use case because you are removing power from the DALI lamps and making them unreachable. You should turn on and off a DALI lamp using DALI commands not removing the device power.

All this being said, if a light is unavailable (HA state) it can go from that state to on, and therefore your automation would still work. The big difference is that HA would recognise that the lamp is unavailable and can not receive any DALI command to turn on/off or dim

[AdamN1]

If the DALI device is powered off you cannot send any commands to it. In a DALI system devices are always connected (meaning they are powered) to the DALI bus and receiving commands even when the light is turned off.

What is the setting 0x2D: "SET POWER ON LEVEL" for? I ask out of curiosity.

Your use case is by no means a normal DALI use case because you are removing power from the DALI lamps and making them unreachable. You should turn on and off a DALI lamp using DALI commands not removing the device power.

I'm aware of this.

All this being said, if a light is unavailable (HA state) it can go from that state to on, and therefore your automation would still work.

Is there a way from HA automation to change this?

If the lamp is unavailable how MQTT message should look?

What about abandoned devices in the mqtt broker and HA, when we delete entry in device.yaml? Are we going to delete them or leave them?

[dgomes]

What is the setting 0x2D: "SET POWER ON LEVEL" for? I ask out of curiosity.

• It's the brightness value the lamp should be set to when power is restored (after a power failure), usually used in emergency configuration where power is lost, a generator is started and light is restored to emergency level (usually less brightness then normal). Remember that DALI is used in commercial environments without wall switches 😉

Is there a way from HA automation to change this?

If the lamp is unavailable how MQTT message should look?

What about abandoned devices in the mqtt broker and HA, when we delete entry in device.yaml? Are we going to delete them or leave them?

Not sure what you want to change...

If the lamp is unavailable, we publish on the availability topic (https://www.home-assistant.io/integrations/light.mqtt/#availability) a False message.

Abandoned devices: we should no longer publish them to the discovery topic. In HA there is yet to exist an API to remove devices... currently you need to use the UI

[dgomes]

What is the setting 0x2D: "SET POWER ON LEVEL" for? I ask out of curiosity.

If you are using this to turn on your lights, I hope you don't have DALI in your bedroom, I wouldn't like to be waken up in the night after a powerloss 😉

[AdamN1]

If you are using this to turn on your lights, I hope you don't have DALI in your bedroom, I wouldn't like to be waken up in the night after a powerloss

In my situation SSR stay off so the light will also be off. But I'm using this for night light startup to prevent flash. I setup this to the lowest supported value, turn on Fade IN. When I turn on lamp the light brightens smoothly.

Abandoned devices: we should no longer publish them to the discovery topic. In HA there is yet to exist an API to remove devices... currently you need to use the UI

Will you to accept PR with code for deleting missing lamps(remove from device.yaml)? By deleting I'm mean cleaning mqtt on the broker by the dali2mqtt. I know it's hack but it will help mqtt entity in the HA to stay clean.

[dgomes]

Will you to accept PR with code for deleting missing lamps(remove from device.yaml)? By deleting I'm mean cleaning mqtt on the broker by the dali2mqtt. I know it's hack but it will help mqtt entity in the HA to stay clean.

if the device is no longer present, this should happen yes

[AdamN1]

Will you to accept PR with code for deleting missing lamps(remove from device.yaml)? By deleting I'm mean cleaning mqtt on the broker by the dali2mqtt. I know it's hack but it will help mqtt entity in the HA to stay clean.

if the device is no longer present, this should happen yes

What you think about comparing mqtt topics from dali2mqtt with topics in the mqtt broker. If we find lamp in added by dali2mqtt that we don't have in the device.yaml and we didn't scanned lamp on startup we need to remove lamp from broker. Are you ok with this kind of approeche?

[dgomes]

...comparing mqtt topics from dali2mqtt with topics in the mqtt broker...

What does this mean ? we only care about dali2mqtt topics...

All topics under dali2mqtt/ are controlled by dali2mqtt daemon and shouldn't be anyone ele messing with these topics

[AdamN1]

...comparing mqtt topics from dali2mqtt with topics in the mqtt broker...

What does this mean ? we only care about dali2mqtt topics...

I mean search broker history for actually unsupported lamps. If we compare mqtt broker history with device.yaml we can find removed lamps and remove them from broker.

[AdamN1]

my point is that we should:

1. always scan on dali2mqtt start
2. we don't find a previous lamp? we set that lamp to offline

No further case necessary, if the lamp is really removed you should just edit devices.yaml and remove the lamp (eventually we can create an MQTT command that does that for you)

I propose add this in couple i smaller commits:

1. support mqtt topic based on entry in the device.yaml and scan result
2. propagate lamp availability based on the scan resolut, lamp is in the device.yaml but scan didn't find it we set availablity to offline

[dgomes]

I mean search broker history for actually unsupported lamps. If we compare mqtt broker history with device.yaml we can find removed lamps and remove them from broker.

you should not depend on mqtt broker retaining topics

[AdamN1]

I mean search broker history for actually unsupported lamps. If we compare mqtt broker history with device.yaml we can find removed lamps and remove them from broker.

you should not depend on mqtt broker retaining topics

let's move this conversation to separate issue #47