The 7th is my birthday. But I celebrate it on the 8th ![]()
So I’m not sure, but if it’s not too late, why not.
Available during the day on the 7th? My birthday is on the 6th and I’m celebrating it on the evening of the 7th, so I’m not available in the evening ![]()
The 8th and the 9th are going to be productive ![]()
He has a lot of cancer
!!
Happy birthday @AlexTrovato!! ![]()
So, call today or not? I’m available until about 4:00 PM if you want
Shit, happy belated birthday @pierre-gilles and happy birthday @AlexTrovato
Available if you’re up for it
Happy birthday to both of you ![]()
I’m replying a bit late, but I can participate until ~2pm today, otherwise I’ll join the next call
Happy birthday @pierre-gilles I’m having a drink right now, can we call?
I’m free all day
Shall we call at 2 PM here? => https://meet.google.com/xxv-emsx-ctt
Well, if you’re up to it ![]()
Sorry I wasn’t responsive, I was eating ![]()
@Romuald_Pochet would you be available for a quick developer call in 7 minutes today?
I see you’ve been active on the Z-Wave topic today, so we can talk with you about it!
FYI, we’re on the call with @AlexTrovato => https://meet.google.com/xxv-emsx-ctt
I’m gutted I missed you all…
Got pulled into an emergency at work all afternoon…
Could you give us a quick rundown if it’s not too much trouble?
And above all, happy birthday @pierre-gilles and @AlexTrovato!!
![]()
![]()
![]()
One cake and one bottle each, no favoritism.
Happy birthday to both of you.
Too bad! ![]()
Here’s a recap!
Lixee TIC and display of complex devices in the UI
-
We talked about displaying complex devices like Lixee TIC which are currently hard to read in Gladys because they have lots of features of the same type. For these devices we’ll probably display the feature name on the dashboard and in scenes. The whole work is to figure out how to detect complex/not-complex devices. @AlexTrovato will look into making a POC, and we’ll need to test the before/after on full installations. The idea is to implement a truly hybrid behavior, and not to generalize this behavior which is really specific to devices that are out of the ordinary.
-
We discussed performance issues when there are many events, this issue being due to the synchronous nature of Node.js EventEmitter. @AlexTrovato will look into making the emission of events done in a « to be done later » mode (roughly), so that Node.js doesn’t block.
Once these two points are validated, for me the Lixee TIC PR can be merged.
Z-WaveJS Migration
@Romuald_Pochet gave us a really promising demo of what he did using ZwaveJS2Mqtt, which runs in production at his place and it really looks great!
Functionally, it looks really good; now before we can merge to production there are 3 things to do:
- Work on the UI so that the end-to-end flow is polished: creation of containers, etc.
- Finish all unit tests, Cypress, etc., so the code is clean and tested
- Find out how many people use the current Open-ZWave integration in production, because basically this new integration will be « breaking » for someone who has an existing Z-Wave installation — if we push it like that, their installation will be broken. I’ll look on my side to get more telemetry on this point so we can track the real usage of each integration. Then, the idea is to see who uses what and which migration plan we put in place.
Apparently @Romuald_Pochet has time in early August when he can make progress on this; since almost all of us are on vacation in August we can do a check-in when we get back, in my opinion ![]()
Otherwise, given that the current Open-ZWave integration blocks us on quite a few issues: upgrading Node 14 to Node 16, very slow CI builds because of that, impossible to update certain dependencies because of Node 14, etc. We all basically said that the goal here is to make a first version « simple but stable », in line with the v4 philosophy: we do things properly but don’t go off in all directions feature-wise.
Am I forgetting any topics?
FYI @Romuald_Pochet @AlexTrovato @VonOx, I’ve made progress on measuring the usage of integrations.
Each service must now expose a function isUsed (optional for now), for example in the case of Z-Wave:
Will this really reflect the actual usage of the services? For example, I use Z-Wave but the service is disabled in Gladys. I manage all my Z-Wave devices with Node-RED
Yes, your devices will not be counted as a Z-Wave service but as an MQTT service.
That’s exactly what we’re trying to determine here — how much the current Open-Zwave service is being used, if at all, so we can decide which migration method to adopt.
Ok, but it’s not going to be easy to know that the device on MQTT is actually Z-Wave.
That’s not the purpose of the feature ![]()