I don’t understand why you want to do that? We didn’t agree that we should just change the feature of the category to a switch (cf Editer le type de feature des devices Philips Hue - #10 par pierre-gilles )
Hi @pierre-gilles,
Well, this follows your own request with @AlexTrovato on this topic: https://community.gladysassistant.com/t/pouvoir-modifier-les-pieces-des-divers-features-composant-un-device-avec-multiples-relais/5935/7?u=terdious,
i.e., keep in mind:
Originally, you wanted to do this with the model. But if we do that, we limit it to Philips Hue. However, there are many outlets like this. Sonoff relays are in the same case.
In short, to keep track of what the original device was, how do you think we can do it other than in the DB. Or maybe I didn’t understand the particularity of your proposal, I’m sorry.
I don’t see why that would limit us to Philips Hue!
Currently, in any integration, when we receive a device, we use the data provided by the integration to decide which device category to assign to that device.
The only thing I propose is that instead of saying « this switch is a switch, period, » we say « this switch is a switch but could be turned into a light, because this switch can have a light connected to it. »
To decide whether to display this toggle, I propose to base it on the same criteria we use to decide if it’s a switch (we don’t lose this data).
I know, it’s really hard to explain ^^
Indeed, my bad, I didn’t write what I was thinking at all ^^. I was imagining creating a common variable listing all the models likely to be affected. Which is nonsense. No problem ^^
Actually, not at all. It’s clear with your explanations ^^ well I think ^^
However, today we agree that we don’t have the tool on the front end to do it because from what I understand, you would like us to:
- create a new action on the front end to retrieve the « lights » variable from Philips Hue and retrieve the category upon arrival at each poll.
- if it’s a « switch-binary » we display the toggle.
- if toggle
we modify the category to light, if unchecked we modify the category to its original state. - and we display the base category in the feature.
If that’s the case, I think I can do it. However, could you look at my proposal on the PR. It is functional and testable. Because in this proposal, all that’s left is to modify in each integration how the device is created (by adding a parameter) and the rest is identical for all.
I just reviewed your PR @Terdious, I don’t think we want to implement the type change feature like this, it doesn’t make sense in terms of DB modeling (it violates many DB modeling paradigms), I find it a bit of a hack there ^^
Ok, thanks for watching and for your feedback anyway.
However, there is nothing makeshift in there. Indeed, on my side, I am an automation specialist / GMAO administrator and GMAO DB. And in our field, this is how we operate, everything that is configuration is always saved in the database, hence my proposal ^^. However, indeed, it may not work the same way in pure computer science. I’m here to learn ^^ if you have time to explain to me how you see things, because I don’t see how to retrieve this data without having to call the device again. In any case, we discussed it with a few people, maybe a column is missing in the device_feature table?
Still very interested on my side to do it!!
I don’t have the answer right now 
I need to dive into the subject, I think we can look at it after I finish the multi-user part? (I think it’s more of a priority, especially for you aha 
)
Absolutely yes!!^^ And on my side, I have Netatmo to finish^^
We’ll see about that later!!
I made a PR proposal for the type change (outlet → light) according to the device model.
https://github.com/GladysAssistant/Gladys/pull/1108
Support for this change is only on the front end, based on a method to determine if the feature category can be modified.
Here, for Tasmota, I know the light type models, so I check if my feature is switch / binary and that the device model is not in the list of types identified as light.
In this case, I only allow editing of the category (not the type).
Great! That’s clearly what was needed in my opinion, it’s pure front-end.
Hello,
I have generated a Docker image with the feature to modify the category of a feature for Tasmota devices, but only if they are plugs.
Thus, a device detected with a « plug/switch » feature can be modified to a light.
The constraints/limitations for modification are intentionally strong to ensure that the triggered action is well submitted.
The modifications have been made to the common graphical component by adding an option that allows changing the category during an edit.
For reference, only for Tasmota for the moment.
If interested parties want to test/check the behavior, here is the Docker image.
atrovato/gladys:change-feature-category
https://hub.docker.com/layers/171261089/atrovato/gladys/change-feature-category/images/sha256-70adc5aeecf3fd192ac2047ba1e63b0fece4f83bb1d96c121a3c5bf1ead386da?context=repo
Once this feature is validated, we can extend it to each service.
Thank you.
Hello @AlexTrovato,
Tests of your PR carried out as follows with a Sonoff 4CH:
- Modification of 2 of the switch features to lighting:
- Integration of the 4 features on the dashboard in 2 separate boxes, one with the 2 switches and one with the 2 lights.
- Tested turning on the 2 switches one after the other:
The main switch of the box does not move (note for @pierre-gilles as well, always the same remark, one would expect it to control all the binaries of the box. So what is the point of displaying it when there is no light in the box?) - Tested turning on the 2 lights one after the other: . The box switch lights up correctly when the first light is turned on.
- Tested turning on the box switch: . Both lights turn on correctly
Next tests: control by category in scenes
-
Good, once again, I know this is not the problem of this PR, but it is better to remind everywhere: @pierre-gilles, it is still impossible to determine which feature it is when there are several features of the same category, whether in the trigger or in the action « Control a device ». Displaying the name of the feature for the corresponding integrations would be necessary.
-
Also, it is still impossible to control a light independently when several lights located in different rooms belong to the same device. But the addition of the action « Control a device » is a good workaround. However, it can still be frustrating not to be able to use the action made for this ^^ The same goes for outlets.
-
Creation of various scenes:
- Trigger: 1st switch on ON / Action 1: Control a device: 2nd Switch on ON / Action 2: Control a device: 1st Light on ON - Ok
- Trigger: 1st light on OFF / Action 1: Control a device: 1st Switch on OFF / Action 2: Control a device: 2nd Light on OFF - Ok
- Trigger: 1st switch on ON / Action: Turn on the light: Sonoff 4CH - Result: 1st light on so ok but 2nd light not on
(Assumption: When a device contains 2 categories Light/Binary, there is no for each provided. The first feature is therefore only taken into account.) - Trigger: 1st light on ON / Action: Turn on the outlet: Sonoff 4CH - Result: 1st switch on so ok but 2nd switch not on (Assumption: When a device contains 2 categories Switch/Binary, there is no for each provided. The first feature is therefore only taken into account.)
- Last test: Restart the container then verification. Everything is well persistent
Hope this helps. For the PR itself, I have nothing to say. Thanks @AlexTrovato
Can you put a screenshot of how the part where you modify the type of features looks?
Arf, it must be noted nowhere because I had completely forgotten:sweat_smile: Sorry!
I created an issue so it’s not lost:
https://github.com/GladysAssistant/Gladys/issues/1312
Sorry, I didn’t have the bug in mind at all.
I created a Github issue:
https://github.com/GladysAssistant/Gladys/issues/1313
This reminds me, we will need to find a way to better organize the git soon because there are so many issues / PRs that I get completely lost, I hardly look at it anymore because it’s a mess…
Ah, the « turn on the light » box was designed thinking that devices of type « lamp » necessarily had only one feature. If this box turned on all the lights of the selected device, would that work for you?
That’s right, the box was created taking into account that a lamp had only one binary feature. If I turn on all the binaries of the device, would that be okay? If it’s okay, you need to create a GitHub issue, otherwise it will be lost in 1 minute
Don’t be sorry at all, clearly I’m mainly responsible, I always indicate things on the forum, but since the beginning I’ve only had to create 1 or 2 issues on Github. As a regular contributor, I should impose it on myself. I admit that I lack time (like all of us of course) and the fact that I usually spend 1 hour producing a post that should take 5 to 10 minutes prevents me very often from going to Github and having to translate it into English… and as I have difficulties in expressing myself well or making too long posts… well I digress. I’ll force myself a bit more!! 
Thanks a lot!
Indeed!! With Gladys V4 growing and now integrating quite a lot of things, it’s getting more complex ^^ It’s a good thing in a way 
Well in this case I really give my point of view on this point, but it will surely have to be validated by others, every time I go through this box, what I expect from it (same for the Turn On/Off the Outlet(s) action of course):
- That it displays all my devices containing at least one lighting.
- That I can choose a device that has only one lighting
- If the device contains multiple lighting features:
- That I can select the entire device (for example named by the device name with at the end « (All lighting) » : « Sonoff 4CH (All lighting) » and that it controls all the lighting features of this device
- That I can select a lighting feature of the device: « Sonoff 4CH - Bathroom Lighting » or « Sonoff 4CH - Toilet Lighting » and that it only controls this feature.
All possible scenarios then become « possible »
It’s clean!
Ok, so if I understand correctly, we need to stop thinking in terms of « device », but always in terms of « feature ».
We should rather replace the device selector with a feature selector.
This won’t be easy to change (we need to migrate the existing), but it needs to be done, I’m creating a GitHub issue for that:
https://github.com/GladysAssistant/Gladys/issues/1314
It won’t be done right away though, it’s a lot of work ^^
Thanks for the feedback!
I had already created an issue about the box switch
Ah well spotted! I’ll close mine
For the feature, functionally it’s good for me.
I provided a technical review of the PR’s code.
@pierre-gilles, @AlexTrovato,
Je me permets un petit peu après avoir relu toute la conversation. On est d’accord que cette fonctionnalité a du coup déjà été déployée mais pour le coup seulement pour tous les devices avec un bouton « Editer » ?
@AlexTrovato, cette fonctionnalité étant liée au front on est d’accord qu’il ne manque plus qu’à ajouter le bouton Editer à l’intégration Philips Hue ? Si c’est bien le cas je vais m’y pencher.
Yes, a similar feature was developed on another integration, but not on the Philips Hue integration.