Sure, it won’t hurt ![]()
However, I think there’s a connection that remains open, but I don’t know when ![]()
Sure, it won’t hurt ![]()
However, I think there’s a connection that remains open, but I don’t know when ![]()
OK.
I will check what is done on the MQTT side and see if there is not a missing connection.close() when we stop the service
Same here, I don’t know how. Could a reboot of the RPi be the solution?
For pairing:
Nothing appears.
After digging a bit, it’s because watchtower redeployed the new image that changes the container names with z2m ![]()
I deleted everything and now it works perfectly ![]()
Hello everyone,
I notice that there are often requests to integrate new zigbee2mqtt devices.
After some research, I found that the documentation referencing all compatible zigbee2mqqt devices is generated from the npm package zigbee-herdsman-converters.
Using the logic to generate the zigbee2mqqt documentation and our way of integrating devices into Gladys, I created a small tool that:
My tool: GitHub - atrovato/Gladys-Zigbee2mqtt-tools · GitHub
The generated files: Gladys-Zigbee2mqtt-tools/generated at master · atrovato/Gladys-Zigbee2mqtt-tools · GitHub
The changes in Gladys: Zigbee2mqtt devices by atrovato · Pull Request #1294 · GladysAssistant/Gladys · GitHub
The tool is certainly not complete and may generate some inconsistencies,
but feel free to help me complete it and improve it.
I still have a question pending, is the version of zigbee2mqtt specified?
Because things are evolving very quickly for them: Releases · Koenkk/zigbee-herdsman-converters · GitHub
@cicoub13 @VonOx @Reno
I especially have a big doubt about the button / switch_sensor / temperature features.
Hope you like it, and that it helps us generate new compatibilities.
Best regards
EDIT: file generation forces sorting by brand / model / features, which generates many changes.
The best of the best would be to exploit what the device exposes.
We can make the service a bit smarter and there’s no need to manage the features.
At my level, I have no idea of the complexity of developing this logic.
In the meantime, your generator is going to save a lot of time ![]()
We use the latest version of zigbee2mqtt via their Docker image
In the end, the tool also exploits the « exposes », but from the server.
So it needs to be adapted to make it dynamic for MQTT discovery ![]()
In the end, if we are able to generate config files, why generate them? ![]()
We can do like Philips Hue, just map on the fly when a new device is returned
I started the topic.
I will try to be as complete as possible.
Great! Keep us updated ![]()
It’s clear that if we no longer have to manually add Zigbee devices, that would be amazing ![]()
Thanks for taking the time!
OK, I’m at the testing phase, but I don’t have any material on this protocol.
I’m looking for MQTT payloads from the topic zigbee2mqtt/bridge/devices to check that the devices/features are correctly created.
Thanks in advance to everyone for your contributions.
Great, I’m going to generate Gladys devices, and we’ll see, once it’s done, if you find all your features again!!!
Thank you!!
The correct topic is
zigbee2mqtt/bridge/devices
Good evening,
My small contribution
Thank you both.
Here is what I generated from your devices.
Each generated device is in its own file (I think it’s more readable).
I’m quite satisfied with the result.
If you have other cases with « complex » devices (lights / switches…), I’m interested.
I haven’t looked at everything, but I mostly have Aqara sensors, so it’s not very diversified in terms of equipment. (Sensors OK)
I have an unpaired Philips Hue, I’ll add it to the network tomorrow to see how it works with a light.
And I also have a smoke sensor that I haven’t added yet.
I’ll send you a complete JSON file.
Good job Alex!
@AlexTrovato I’ve paired the smoke sensor and added a lamp
New revision of the gist
https://gist.github.com/VonOx/f47cdcd0550ccd125084a93e6aaca997
Here are a few more devices
Great idea to generate the features from the library code, I hadn’t thought of that. I had stopped at the fact that these JSON files did not contain the exposed features.
But as @pierre-gilles said, might as well go further and do it on the fly.
I don’t have much time to look at this week, but if you propose a PR, I’ll take some time in the coming weeks to look at it.
@cicoub13 the generated ones from your payload come from changes in Gladys, generation on the fly.
Once the devices are correctly generated, I will propose a test image to validate the integration with MQTT.
My first task, generate the devices / features according to the data received dynamically.
@cicoub13
The payload you provided does not come from the correct MQTT topic: