I confirm, it’s still on hold for now, I’m following the developments of the Bluetooth libraries and regularly test their compatibility.
Hello everyone,
I completely agree with the priorities you indicate except for multi-users, which, in my opinion, is not essential at first. Once the scenes are functional and rich enough to trigger actions based on the presence or absence of people, it will be more useful. But for now, I don’t see much use for it. At my place, whether we use one account for everyone or each has their own, it doesn’t matter for now.
I would rather focus on finalizing Sonos instead. Even if it’s not essential for a RC, it’s just a nice to have. I say that because once the Sonos integration is done, you also manage Deezer, Spotify, Amazon Music and co. Not directly of course, but it already allows a good approach.
Given the schedule, I think we should indeed keep Z-Wave and Scene as top priority.
Don’t forget to integrate the improvement that someone had proposed for the weather service. I think there is a PR in that regard.
I was thinking about something we had already discussed, the list of compatible devices.
The list is starting to grow.
Thanks for your feedback @link39, indeed my focus is clearly on 1) the scenes 2) the Z-Wave, and if I have time the multi-user but it’s unlikely before the RC! The finalization of the Sonos I don’t think it will be possible given the little time left (8-10 days of development), knowing that I don’t have a Sonos to test…
The weather box I had made returns to the PR, unfortunately I have no news from the person who made the PR since July 
It is therefore on standby until he wakes up/ or someone does the fixes in his place!
Well spotted! The debate was never finished in fact. I create a topic to talk about it right away.
Edit: created:
Yes, I had started but unfortunately I have personal setbacks and I can’t move forward with it… If someone is eager, don’t hesitate!
I will get back to developing Zigbee2mqtt to integrate the latest comments.
I am willing for this service to be included in the release.
Thanks @Reno! It’s great, I’m sure many will be happy to see this service 
I’m trying to make progress as quickly as possible on CalDAV so that it’s ready on time. Your various points in the review have almost all been fixed, only the longest one remains, which is incremental synchronization, I think I need to make quite a few changes. I will keep you informed.
@pierre-gilles the new issues are not linked to the project, and I cannot edit the « project » attribute from the ticket.
Could you check for:
- either creating the tickets with the default project?
- or allowing the assignment of the project?
Thanks.
Hello
Will the broadlink module be integrated for the RC?
It works well for me
@pierre-gilles you said that « later » gladys would be able to make html requests? Is it integrated into the scenes or is it a separate module as well? (Integrated into the RC?)
Last question, my zwave peripherals are still half-managed (problem with too old lib) if I understand correctly, it’s only after the scene interface is ok that the library will be updated, right?
Thanks
For the broadlink, it might be compromised due to discussions about quality, technical complexity, and some design points.
I just gave access to the board to the « Gladys Core » team, normally you should be able to access the project Let me know if that’s the case
I assume you mean « HTTP ». It will be a separate service. To my knowledge, no one is developing it yet, so I don’t think it will be integrated into the RC! My priority for the RC is the scenes.
For the version of the Open-Zwave library, « sescandell » on GitHub is working on it, I hope he will finish before the RC!
See:
In fact, I can do it directly from the project.
Same @pierre-gilles I can’t assign an issue to a project.
I think this is a GitHub bug or an oversight on their part. Here’s what I’ve enabled on my side; I don’t see what else could be needed…
The « core » team does have « Write » access to GitHub projects:
All organization members also have access to the projects:
Finally, « core » members have « Triage » access to these two repos, cf GitHub doc
If you see something, I’m stuck!
Don’t worry, it’s not that serious. You’ll take care of it 
Hello everyone!
Quick message to keep you updated on the development progress for this upcoming RC release
Progress
- Regarding the progress of the « Scene » view, development is going well but I’m spending a lot of time on small UI details to make the experience really good, so it’s taking longer than expected. I think it’s worth it, this view really needs to be clean
- Regarding the update of Open-Zwave on the Docker image, I’m still waiting for feedback from « sescandell » on GitHub. Apparently, he’s quite busy at the moment. If anyone has time to look into it, here’s the GitHub issue!
Next Steps
Once the scene view is ready, I think it will be time to start translating Gladys 4 into French and to start building Docker images without the « beta » tag.
On my side, I will make a new Raspbian image with all these changes.
I saw that there are also PRs ready to be reviewed, I will look at them once I have finished the scene view which is for me the priority number one at the moment.
I’m doing everything I can to meet the announced date, after all, I was sick yesterday and therefore lost 1 day of development on the only 8 man-days left before the release on February 21st, it may seem little but it’s a lot 1 day of development 
I’m open to any help if any of you have availability to lend a hand!
Hello everyone,
I’m also sharing updates on the Zigbee2mqtt service.
Unfortunately, I haven’t been able to dedicate as much time to development as I had hoped…
I only got back to it last night, but I managed to modify the rendering for the Zigbee2mqtt service based on the Zwave service. It is now possible to modify the names of the features of the devices, information that is displayed in the dashboard.
However, I’m not entirely convinced by the rendering when there are multiple sensors in the same room.
Here is an example of what it looks like:
- Feature editing side:
- Dashboard side:
What do you think?
This view does not allow you to see which component each « Battery » corresponds to, but since this information should not be displayed in the long run…
Shouldn’t we group (in a slightly darker frame) the features that correspond to the same component?