Hi @pierre-gilles
I noticed you marked zwaveJS integration as deprecated, is an external integration coming?
I’m asking myself the same question?
Eventually, all integrations will be external, right?
Except for MQTT, ZigBee, and I don’t know what else…
It was @Sescandell who deprecated it, I’ll let him answer you, he manages the entire Z-Wave part 
An externalized version is currently being finalized here: GitHub - sescandell/gladys-zwavejs · GitHub
I took the past week off for vacation I’ll pick up the topic this week to publish the new integration properly (once better tested in real conditions). I do not yet recommend trying to migrate to it except for testing purposes: I haven’t done enough testing yet.
Welcome back @Sescandell 
A few questions about this external integration.
- Are you exactly taking over the current integration?
- Will we have a docker zwavejs to manage EVERYTHING via Gladys (keys, devices, associations, etc.)?
- Will we be able to choose between an external and internal zwavejs installation?
- Can we have an associate/dissociate button?
- Are you going to add energy consumption tracking?
Basically, I no longer want to go through Jeedom to manage my Z-Wave network but through Gladys, which lacks management features, in addition to the existing mapping.
Hello,
Oula, so much to talk about…
What’s your situation, I don’t understand the starting point?
Yes… in fact, that’s the whole point behind this externalization: in a first step, don’t change anything, just make sure we get the same functionality, but via an external integration and no longer depend on Pierre Gilles for developments (he actually pushed me to do this following a zWave development PR).
No, that’s not the primary goal. The primary goal is « just » to replace the internal Gladys integration with an external one. But zWaveJS and an MQTT server must already be available somewhere on the machine.
We can look into that after V1. But it will also require developments on the Gladys SDK side. Adding a zWave node requires several steps and validations. I don’t think we have everything we need in the SDK yet… we can look and see what’s missing.
What’s missing for you on this subject? I can easily add missing data.
Why go through Jeedom and not directly the zwavejs interface? That’s where I manage the associations and specific debugging needs. I actually rarely go there (adding a node… debugging during development, but otherwise…). What do you do specifically in Jeedom?
Thanks for your feedback @Sescandell, I completely understand an initial integration identical to yours.
Well, the 30-minute consumption and 30-minute cost that weren’t implemented in the internal integration for all electrical devices that manage electrical energy in addition to power 
Actually, for now, it’s Jeedom that manages the docker zwavejs.
Yes, I know, it’s lame, but I had switched from openzwave to zwavejs before tackling with Gladys on my modules.
And I also use it to associate/dissociate, perform a network health check.
Well, I missed something in zwavejs 
, and if you have screenshots of the association button, I’d be interested.
So the idea of a V2 that manages the docker zwavejs would be great for me 
It’s on @pierre-gilles’s to-do list to implement this for all integrations
A bit of history 
.
At the beginning, Gladys had a rather old Z-Wave integration.
@pierre-gilles then decided to remove the integration and the devices were converted to MQTT.
Then came zwavejs. I never had the option to remigrate via a button. And my devices were present in quite a few scenes.
So I never took the plunge with the new integration.
Isn’t this already handled?
There is a world where, by simply adding the « Migrate » button to the Gladys MQTT interface part, it would work. The migrate button actually only does database manipulation: it realigns the IDs and removes the original device.
From afar, I would say: yes, it would be enough to add the migrate button to MQTT. But since this is not the primary intention of this button, adding it systematically to this integration could be disruptive. In my opinion, it goes beyond zWave. It’s up to @pierre-gilles to decide what he wants us to do.
For your information, it’s already implemented and will be available in the next version of Gladys. 
In this case, I think @spenceur’s situation is really a very particular one. As he is a developer, the simplest solution is probably to handle his case directly, rather than adding a button in Gladys that would hardly be useful to anyone. 
@spenceur: the API that allows migrating a device from one integration to another is open and works with all integrations. You can ask Claude to generate a small script for you to migrate your two devices. What do you think?