Hmm, it seems I have nothing new to pull under this tag, I’ll try again a bit later (probably tomorrow, not available tonight).
Oh ok, I spoke too soon, it seems there are still ~45 minutes before the image is ready 
New test with the new image, but it seems that the « Save » button does not change, even after re-adding the device 
The device disappears upon addition… Then reappears upon page reload.
Good news!
Contrary to what I thought, I had brought with me one of the switches that I had requested to be added some time ago (Zigbee2mqtt: Add device ZM-L03E-Z · Issue #1244 · GladysAssistant/Gladys · GitHub) and it works too 
This makes me sad. Can I hope that you tested incorrectly??
The device disappears? The button is not changed to « Already in Gladys »? And after reloading, it’s still « Save »? Not « Update »?
Okay, I’ve reproduced the issue, and indeed, it’s a silly error in the ID detection…
New image with the fix is being built, it will take 1.5 hours before it’s available.
Good, now I have « Already created » on the devices that are registered in Gladys.
By deleting a device (from Gladys, then Z2M), I can reintegrate it directly into Gladys without any issues; the « Save » button comes back in place of the « Already created » button.
I think we’re pretty good then 
P.S.: While I’m at it, I did some tests and noticed an inconsistency with the scenes when deleting and re-adding a device. In the « Turn on/off the light » type blocks, the device is correctly removed when it is deleted from Gladys. Once removed, it must be manually put back into the scene. On the other hand, in the « Control a device » type blocks, the behavior differs slightly. Editing a scene after the device is deleted keeps the device’s control block (but not filled). However, if the device is re-added before any new scene save (i.e. between deletion and re-addition), the scene retains the device’s pre-deletion properties.
Ok, that’s a bit much.
However, for a scene bug, I don’t think we should discuss it in a zigbee2mqtt topic, otherwise we’ll lose people.
Thanks for testing @Shiftmaj, it’s great to get feedback, it allows us to merge more confidently (I don’t have this equipment)
I just merged the PR from @AlexTrovato!
@AlexTrovato Can you confirm that what we have on master is « production ready »? Any known bugs left?
On this part, I am not aware of other bugs related to the evolutions.
I am rather calm.
(I have the impression that someone wants to close about ten GitHub tickets on the subject :p)
Otherwise, I would be able to make myself available.
Great! Aha, this isn’t for me, it’s for people who ask for these compatibilities
It’s really going to be cool once we have this auto-detection in production.
So I’m testing my new toys, so far no major issues, great job on this service 
I just have a question about this kind of device Philips 929002398602 control via MQTT | Zigbee2MQTT it’s a kind of remote control/switch. If I understand correctly, the proper way to turn a light on/off from this type of device is to use scenes. But it seems that this is not possible. In the triggers, I have put Device state change, I have chosen my remote control then equals and there I put the value on_press (the zigbee2mqtt doc indicates the list of possible values) unfortunately when saving, error with \"[0].value\" must be a number as a message in the developer Network tab. Is this just not implemented yet or is my solution not the right one?
Sorry, but indeed, this type of device (remote control / cubes…) is not fully managed.
The values are non-numeric actions, and we have not yet studied (to my knowledge) the appropriate way to handle this type of value in the Gladys core.
And on zigbee2mqtt, the values in the form of a string are almost unique to each device.
We need to handle each case individually and create a specific component in the UI to manage the values
Several possibilities:
- Either we do a mapping with numerical values (which allows us to have the history). For example, « click » = 1, « double-click » = 2, etc… and then we need to display a specific component in the UI that displays a translated value.
- Or we do not do any mapping and we use the « string » states of Gladys 4 (yes it exists ), but then we lose the history of the values. And likewise, we need to create a specific component in the UI to translate the values
For your information, the new version of Gladys integrates Zigbee2mqtt with automatic detection 
Thanks to @AlexTrovato!
It seems that the library used by zigbee2mqtt provides a list of statuses for each action zigbee-herdsman-converters/devices/philips.js at 05f0795cbf3742a17d59152bbe2186ec6bc8a48e · Koenkk/zigbee-herdsman-converters · GitHub
Perhaps this second solution is simpler? It seems to me that the only place where we need these states is in the scenes, so keeping the strings may be a good solution and knowing that we can have the list automatically (so a select for the scene trigger conditions).
For information, we can see that the states are well detected by Gladys, here is what it looks like on the dashboard.
To go back to the history of devices with « string » value,
- It should be possible to integrate this into the scenes, as a double click could allow triggering a scene (I think that would be great)
- indeed, the « string » states exist, but the management of these is quite limited for the moment (according to the cameras), so not exploitable as is
Now, this may be « complicated » (not impossible) to succeed in making an exhaustive and coherent mapping between all possible states of the devices and integrations and Gladys.
For me, the simplest would really be to make a mapping in numerical value, but in terms of UI, the display may prove complex given the number of states and their variants.
@Tolkyen
I’m pinging you here regarding the Zigbee2Mqtt multi-outlet.
If you’re motivated to test, I’ve created a new Docker image that should handle your device: atrovato/gladys:zigbee2mqtt
If you’re not « used to » installing test images, I wouldn’t recommend trying.
PS: for everyone, this image includes an update on device control and a fix on the state change of actuators
@AlexTrovato Regarding the power strips, do you think it will be possible to implement the functionality we discussed at some point with the splitting of power strips into multiple devices (natively)?
The idea is to allow the user to distribute the different outlets in different rooms, to enable the control of each individual outlet in the scenes, and for these outlets to work with voice assistants
Yes 100%, it’s not coded, but what I meant is that it’s not something impossible, and in terms of data model/DB, we already had the functionality with the cameras.
After that, yes, we need to adapt the scenes / and a bit the core to properly propagate these states.
It’s a bit the problem of double mapping indeed, it can quickly become a mess ^^