Hello everyone,
Great work @pierre-gilles.
Quick question, if I understand correctly, we no longer have a store for modules/services. Will all services therefore be in the Gladys core and loaded at startup?
I will start the migration of the CalDAV service to Gladys v4 as soon as possible.
Thatâs a real advantage of the time difference, when you sleep I work 
Top! But for that, you donât need the REST API, you can do it internally.
Completely 
I think this topic is very good, if you want to work on a subject, you can talk about it here! Then as soon as you start working on it, the earlier you create a PR the better it is (you can indicate on GitHub that this PR is in progress)
Indeed, this service is crucial. Itâs actually a good example for me of a service that will be in 2 versions:
Exactly! Thatâs the goal of this v4, to bring a consistent experience and a complete product that we master from end to end.
The CalDAV service is interesting, for now I havenât made a calendar service in Gladys 4 yet so there will be a small part of reflection before development.
I think itâs worth it that we think about all this together Donât hesitate if you have questions, or even to call, Iâm available!
Hello, Iâm still a bit skeptical about the module store disappearance part.
Will all the old modules become new services in the v4 repo? Or only the services that allow a new protocol?
I donât want to be forced to load 1000 services just for one that interests me.
I must have missed somethingâŠ
Yes I want Gladys to be a consistent, turnkey product that works from the start without having to tinker like it is today.
(Note, there will be no redundant services, there will be only one Bluetooth service, only one Philips Hue service, etc.)
With the currently separate modules, it creates tons of problems. When you install a Gladys 3 module, Gladys does a git clone + NPM install + reboot of Gladys. And weâre not even talking about integrating the module into the UI, which has never worked correctly in Gladys 3 and we had to make awful hacks for it to work more or less⊠When I see the number of forum messages where some people have a UI that has crashed because of the installation of a module, itâs not normal that it should be possible!
Everything that is currently done on the user side when installing a module should only be done on the developer side.
After that, I think you overestimate the size of a service⊠A service is generally a few JS files, weâre talking about a few kilobytes of code⊠I donât see how it makes Gladys heavier
In fact, I think we should see Gladys 4 differently from Gladys 3, itâs not the same product.
In Gladys 3, I naively thought that my role in creating Gladys was to create the platform, but to leave the « module experience » separate from the core.
But what I underestimated is that what a user will remember about Gladys is the overall experience they had. If they install Gladys, install the speak module, and Gladys crashes. (and we canât do anything about it, « npm install » often fails for external reasons like lack of RAM, NPM downtime), their feedback will be: Gladys doesnât work and itâs unstable.
My paradigm for Gladys 4 is that services are an integral part of the product, theyâre not details: theyâre the heart of the Gladys experience.
I want the user to use Bluetooth to simply check the « Bluetooth » box in the interface, nothing more.
And for that, it requires having the services at the heart of the product, with the same rigor of development as the Gladys core:
This is the only way to have an overall experience that we can control from end to end
Donât hesitate if you have any questions or concerns about all this, this is a part that I have thought about at length and I have only put the main points here. We can also talk about it live at the community call on Sunday!
In the worst-case scenario, weâll create a service to load « plugins » 
But I understand the idea, either we have an open solution, perhaps too open (v3), or a stable and controlled solution, subject to constant validation by the main team (you), v4.
The only thing Iâm afraid of is that if a new feature request is made, it will take too long to be integrated.
Aha that would bring back the problems of v3
Exactly! After that, I think youâre worried about my GitHub merge rate, Iâve thought about it and I think itâs going to be quite different from v3.
On v3:
On v4:
A lot of time will be saved on this.In fact, having everything in a monorepo changes a lot of things.
Hi @pierre-gilles,
great job, it seems to be progressing well :D!
I have a few questions:
There are quite a few modules now, and I think itâs going to be a lot of workâŠ
Next, I admit I share @AlexTrovatoâs concern about the internal services.
For example, if someone wants a Phillips TV service (just in case [https://community.gladysassistant.com/t/recherche-module-philips-tv/4667/5]), will they have to wait for it to be done and deployed?
Does this mean I wonât be able to develop a service for which I donât have the hardware and have it tested by a member like I did with @Jean34 and the Viera TV before deploying it to production?
I thought I understood that some modules would become services but not all, unless Iâm mistaken 
Small suggestion:
Let me explain, there are days when I donât want to wake up at 7:00 a.m. and sleep in. But for now, itâs not possible to stop the alarm, only to delete it, like scenarios.
Wouldnât it be better to have a large TV service that would gradually integrate models?
But I agree with you, it will be a bit more complicated to broadcast something to testersâŠ
I canât imagine the hassle it would have been with @piznel and his Xiaomi module if we had to touch the « core » all the timeâŠ
Not yet! For now, my focus is really on having Gladys core + services as advanced as possible, to be able to release an alpha as soon as possible
I would say that I count on each V3 module developer to help migrate their module to Gladys 4, with my help of course. After that, the most important thing at first is to have the « essential » services (Z-wave, Philips hue, Milight, Bluetooth, Xiaomi, etc.), the other services will arrive gradually depending on everyoneâs availability!
After that, I just looked and on the V3 module store we have 54 modules published. Nothing bad to migrate!
Nothing prevents you from sending a beta version of Gladys to another user. For the record, the installation of Gladys 4 is radically different, itâs just a pull of a Docker image, so nothing prevents having in the update UI an advanced option to update Gladys via « preview » image.
In fact, in Gladys 4, you have to see Gladys as a complete product. When you just sent a module to test to a user, they didnât necessarily have the same version of Gladys as you, if you were waiting for a PR that was pending on the core, you were stuck. Now Gladys is a whole, so a priori if you send them a ready-made image, everything will work as at your place.
Yes!
Itâs already the case!
Each configuration page of a device brand has a rich tutorial that explains how to configure the device. I encourage each Gladys contributor to build rich and complete UIs for integrations
Example:
I think weâll find solutions for development On the contrary, the memory I have of the Gladys 3 module development processes is rather that it was horrible ^^
If you browse the topics « Zwave », « Snips » or « Rpi infos », you have a lot of UI problems that jump, or silly bugs that should never reach the end user, and which are only due to development process problems.
I agree that we will lose a bit of agility, but we will gain a lot in product reliability and security. This is what Gladys currently lacks to convert users looking for a serious home automation solution.
And regarding this, couldnât we leave a space like the v3, to load a module from an external repository? This would make it easier to test a module before it is integrated into the core?
Not really, the Gladys production image will be a very different built image from your development installation. To be as minimal as possible, it will be delivered without any build tools.
And even then, it wouldnât make sense, I repeat: there is no longer a notion of modules, the services are in the core! Itâs one and the same software.
Developing a service, my first opinion:
Hello, I spent my weekend developing (I donât say migrating) a service for handling Bluetooth. The vision is now quite different, as it is clearly necessary to develop two parts, the front and the back.
The front: preact is magical, as are the developer tools provided with it. You change a page, you save, your browser refreshes, and you see the result directly⊠itâs a real pleasure. And preact is so pleasant to code. But itâs quite complex to integrate with the existing system, and the risks of git conflicts between the different modules will be considerable.
The back: we remain quite close to the old modular system, a service that remains quite independent at the code level.
Big advantages to having separated the front from the back, you can really develop one without the other with mocked URLs, but the integration phase is not neutral either.
However, we are clearly on a version currently in development, not finalized, so I think it is important that everyone can note the points not yet covered in order not to forget anything.
And I admit that the final result once the integration is complete is really nice.
I am already thinking of a system of service sub-modules, device modules. But it will be very difficult not to develop in the v4 repo.
Small remark, I still find it quite annoying to load the zwave, philips-hue and other libraries, when I will not use these services.
See you later for the next steps.
Hello @pierre-gilles, I just watched the call you made on YouTube for this month.
I thought about something for the « integrations » tab.
When the user clicks on « integrations », they find all the modules they have installed.
This adds a page but it will be clearer for the user.
Then below the list of devices, communication, calendar, and others that I see as a list of possibilities.
We could call it « Store » one day there might be paid modules.
There are more modules in V4
If Gladys turns into Jeedom, it wonât work. I donât think thatâs the philosophy of the project.
Hello everyone!
I had a relevant question yesterday during the community call: When will Gladys 4 be released? 
Until now, I avoided setting a date because it was difficult to quantify the developments still in the « research » and exploration phase, and I didnât want to ruin the product by setting a date that was too ambitious (or conversely take my time by setting a date too far away). And above all, I know from experience that if I announce a date, I risk disappointing if the date is not met. But today, now that the first backend milestone has been reached, the remaining steps are quite clear and it is possible to set a release goal! This allows us to set a common goal and avoid dragging out the developments.
Here is the roadmap that I propose to you:
I have planned 1 month to migrate the services from Gladys 3 to Gladys 4.
I am not talking about all the services, at least the essential services:
Devices
Total: 12
Communication
Total: 3
Calendar
Weather
Total: 1
Navigation
Total: 1
This roadmap leads us to a feature freeze on Sunday, June 23, for a first alpha release on Wednesday, June 26.
What do you think?
I will create all the tasks and all the milestones in GitHub so that we can have a vision of the progress and that we can distribute the tasks and see where each one is.
GitHub issues/PR will be the main platform for communication for this development.
Exactly!
Glad to hear you also enjoyed the dev comfort offered by preact! For the git conflicts, for me Gladys is just one single product, so after that itâs general git development, if we do it properly there are no problems
100%! Itâs not finished, as I said weâre only at the backend milestone v0.1
This will no longer be the case in the final version, I need to load these libs only at the start of the service and if the user has configured them. Good remark.
Neither one nor the other. Gladys 4 is a unique product, there is no more separation.
Hello,
it all depends on the availability and the number of developers.
As for me, from late May to early July, I will have much less time available.
PS (off topic): for the Bluetooth module, I plan to implement a « distance of nodes » system as you suggest for ZWave, it will be interesting to modularize this part, so as to remain display-agnostic.
For this, I will create all the GitHub issues (one per module to migrate, one per remaining core feature) and everyone can indicate if they want to help with certain issues. I will handle the module/migrations issues where no one speaks up.
Personally, I spend my days on this, so I think in 2 months I have plenty of time to take care of many remaining topics!
Mm ok I will create the Bluetooth module issue, we will talk about it there!
