Level names of selector switch are reset. Topic is solved

[EddyG]

See: viewtopic.php?f=59&t=37823
It works to rename the level names from the defaults to my preferences.
BUT. after a message from zigbee2mqtt of this device all levelnames and levelactions are reset to the defaults.
Even the manual set selector style is reset to the default of 'button set' which does not show good with 18 levels.
What can de done about that?

[jvdz]

Nothing in Domoticz as that is what AutoDiscovery does, which is setting the Level names to what is defined in the CONFIG Payload.
Not sure if you can make any changes on the zigbee2mqtt side for these options in the Config?
Else an DUMMY Selector could be an option, with some scripting to make the relation between options.

EDIT: Didn't we already cover this topic a short while ago either here or in SLACK? (or is it just my memory being messed up )

[EddyG]

No nothing can be changed at zigbee2mqtt side, that service could not know anything about the levelsnames, because that is not in the device.
But the question is: I fully understand that at creation time something has to be set as default from the CONFIG payload, but why has the NAME to be reset every time there is a 'normal' message?

There was some discussion on Slack, my (brain)memory does not have an exact recollection.
The max. of 10 was discussed for sure.
I had my zwave devices (10+ devices) transfered to MQTT AD, but waited with ZIgbee (50+ devices) until a lot more was settled.
Now I am in the progress with my test server to get things done. So I stumbled on this issue, which I don't have with the plugin.

[EddyG]

B.t.w. The selector style is also reset to "button set" style. and that does not work with 18 options.
As far as I could see the reset of the selector switch was not handled on Slack.
But may be I did not search good enough.

[jvdz]

The Selector Options are updated when the Current settings in Domoticz deviate from the Received CONFIG setting as the assumption is that we must have received an update from the Device via the Config since they aren't the same.

[EddyG]

I hope that that logic will be reviewed because it does not make sense that I have a selector of 18 item, of which each has his own name as a melody, with only numbers to select from. Besides that a selector switch with 18 item should be only style 'Select menu', but when I change to that style it is reset back to "Button set" style, which screws up the screen.
And it can be done, because my Z2M plugin works that way. And as I remember it also works that way in OZW.
Besides that I would like my button text look nice, like "Low" "Medium" and "High" on the buttons and not the lower cast from the device.
And perhaps some people even might prefer totally different text.

[jvdz]

I understand it isn't convenient in your use-case, but let's not say that it doesn't make sense what I have explained on how things work at this moment!
To me it makes perfect sense that for an AutoDiscovered Selector device, the CONFIG message with its listed options is leading and should be followed at all times. Agree?
Like we discussed earlier: Make a dummy Selector with your own options and logic when you want to be able to control it yourself via a Script or NodeRed.

[EddyG]

I can agree with you that things work as they work now, because of the route that is followed.
I can handle the devices with scripts, as I do with a Wallmote, which creates 13 devices.
From a user perspective this still does not make sense, because a lot of users will not be able to solve that easily.
I appreciate the effort and time that all developers put into Domoticz.
I just hope that in the (near) future a solution will be found, to accommodate the possible problems from novice users.
Still a small change could be that above a certain number of selections the "Selector Style" should change to "Select menu"

18.01.2022_18.48.35_REC.png (21.83 KiB) Viewed 3283 times

[jvdz]

I can agree with you that things work as they work now, because of the route that is followed.

Ok... so enlighten us with your logic how this should work and make sure it can be implemented in a way it will work generically.

Still a small change could be that above a certain number of selections the "Selector Style" should change to "Select menu"

True that could be changed but this is also an simple one for you to make and that change isn't lost as far as I know ......right?

Just for the records: This is my view on this topic, but maybe @gizmocuz has different views and it is his baby.

[EddyG]

Ok... so enlighten us with your logic how this should work and make sure it can be implemented in a way it will work generically.

Good one, you know you are better then me in programming, but I will think about it.

My solution so far.

Code: Select all

return {
        on = {
                devices = { 'Sirene Melody', '$Sirene melody' }
        },
        execute = function(dz, item)
                local level = item.level
                if (item.name) == 'Sirene Melody' then
                        dz.devices('$Sirene melody').switchSelector(level).silent()
                else
                        dz.devices('Sirene Melody').switchSelector(level).silent()
                end
        end
}

[EddyG]

Ok... so enlighten us with your logic how this should work and make sure it can be implemented in a way it will work generically.

So I took a dive in the source.
1. I see that the selector device is created when it does not exists.
2. I see that 'SelectorStyle' is hardcoded, so could depend on the number of selections.
3. I see that at every value update the 'optionsMap' is also updated.
4. I think that the assumption is that after creation of the device the select options might change. I think that they don't.
5. So I changed it in the way that optionsMap only get updated at creation of the Device.

Cautious I might say it works.
Is the assumption wrong? So what am I doing wrong? What did I oversee?

Edit: I did the same for the climate selector device, and my change in Low, Medium, High (instead of low,medium,high) stays that way.

I also found out that with the melody selector switch 18 selector levels (ranging from 0 to 170), that there is a problem with level 0.
It is not selectable!

[jvdz]

It is not as simple as you think it is.... so let me answer them one at the time:

So I took a dive in the source.
1. I see that the selector device is created when it does not exists.

Correct

2. I see that 'SelectorStyle' is hardcoded, so could depend on the number of selections.

Correct ... and like I said, is indeed an possible option to propose both these changes (but it is not up to me) :

• Change the style when more than X (?) options.
• Keeping the previous saved style, which is now overridden with 0 each update.

3. I see that at every value update the 'optionsMap' is also updated.

Not really ....only when it is different from the current DB value:

Code: Select all

	if (newOptions != sOptions)
		m_sql.SetDeviceOptions(DevRowIdx, optionsMap);

4. I think that the assumption is that after creation of the device the select options might change. I think that they don't.

Dangerous assumption and is up to the Source of the MQTT message, but we assume at this moment that it is a possibility a Gateway doesn't make an update to the list... which I think is fair and were the control over this should lie.

5. So I changed it in the way that optionsMap only get updated at creation of the Device.

You have made the change already?
The reason is that the optionsmap can also be supplied in the STATE update at a later stage in stead of the CONFIG message.

Cautious I might say it works.
Is the assumption wrong? So what am I doing wrong? What did I oversee?

Do you still think it would?

Edit: I did the same for the climate selector device, and my change in Low, Medium, High (instead of low,medium,high) stays that way.
I also found out that with the melody selector switch 18 selector levels (ranging from 0 to 170), that there is a problem with level 0.
It is not selectable!

Not selectable meaning you can't click it in the Web interface?

[EddyG]

Tnx for your answers.

Dangerous assumption and is up to the Source of the MQTT message, but we assume at this moment that it is a possibility a Gateway doesn't make an update to the list... which I think is fair and were the control over this should lie.

What if the assumption is right?

You have made the change already?
The reason is that the optionsmap can also be supplied in the STATE update at a later stage in stead of the CONFIG message.

I would like to see a device with selection where those differ from each other.

Do you still think it would?

Lets wait and see if there will be a problem.

Not selectable meaning you can't click it in the Web interface?

I wonder why?

[jvdz]

The last one was a question from my side.. so I do not understand your answer "I wonder why?"!
So the answer is Yes to the question.?

As for the rest: I am not seeking for our agreement and merely explained why I think it works the way it does... Till now I don't see any reason for changes other than the possible mentioned improvement points. Those are up to. @gizmocuz whether he would like to see them.

[gizmocuz]

I have a patch ready but I'm waiting for some other feedback before merging this

1. Selector style will be initially set to buttons if there are less then 6 items, otherwise menu style will be used
2. Level Off will not be hidden by default

If a new config is received

1. Selector Style and Level Off state will be set to the current state in Domoticz (when someone changed it in Domoticz, this state will be used)
2. Amount of Level names is compared to the current state, if the amount is the same, the level names will not be changed (when someone changed it in Domoticz, these names will be used)

I think this solves the problem

[EddyG]

Tnx, I wait for that.
It's not my intention to cross post.
Just thought that github was the place to place 'formal' requests.

[gizmocuz]

@EddyG, no it is for code bugs and issues and even as this is considered a issue, you are on Slack, you participated (Thanks!!!) in the MQTT channels so a logical step would be to continue there.
I'm not on the forum 24/7, I do on Slack (well... sort of ; )

[gizmocuz]

Could you try beta 14098, hopes that solves the issues... If not, please join Slack again for better communication

[EddyG]

Excellent service, fixed.

[ksacca]

2. Amount of Level names is compared to the current state, if the amount is the same, the level names will not be changed (when someone changed it in Domoticz, these names will be used)

Sorry to relaunch the discussion, but I was doing some test on levels of a selector.
I'm currently working on integrating daikin airconditioning units using mqtt autodiscovery and node red. One user sent me an example and his unit supports a special mode that I had not seen before. I'm adding support for it (which already works), but I would need to update the existing selector to support the new mode. If I understand correctly, if I add (or remove, as long as the count of options is different) an extra option, the switch should be updated.

I did some test on the latest stable and the latest beta, but I can't get this to work. Below is an example where I changed the levels so it's more clear.

topic: testAD/select/fandirection/Hobby_Ruimte/config

Original config payload

Code: Select all

{"name": "Daikin Hobby_Ruimte Fan Direction", "command_topic": "daikintest/select/fandirection/Hobby_Ruimte/set", "state_topic": "daikintest/select/fandirection/Hobby_Ruimte/state", "options": ["1", "2", "3"] , "unique_id": "test1"}

Updated config payload

Code: Select all

{"name": "Daikin Hobby_Ruimte Fan Direction", "command_topic": "daikintest/select/fandirection/Hobby_Ruimte/set", "state_topic": "daikintest/select/fandirection/Hobby_Ruimte/state", "options": ["1", "2", "3", "4"] , "unique_id": "test1"}

So in the first example the selector contains 3 options. I would assume that if I send the second example (which contains 4 levels), the switch should be updated to support the new levels.

In MQTTAutoDiscover.cpp at line 2259 and 2260 I see that there's a check to see if we have new options, but I can't get this to work.

Code: Select all

	if (newOptions != sOldOptions)
		m_sql.SetDeviceOptions(DevRowIdx, optionsMap);

Was anybody able to add extra options to a selector switch? If so, how did you proceed?