Okay, I’ll block my 21 then!
The 20th works for me too! 
I disagree! Sails.js is becoming outdated and is hardly/ no longer updated. It blocks us, and above all we currently have little freedom in the execution of modules, which creates all the module execution problems you can see on the forum.
It certainly doesn’t add any features to migrate, but it adds a lot of stability. And stability is a feature for me!
On the Preact side, there are big advantages to migrating:
- It’s a PWA, so the interface will be much more responsive for the client
- Preact vs AngularJS is incomparable in terms of client performance
- In terms of development it’s still more pleasant. Currently we are stuck with AngularJS tooling and we would like to be able to use ES2018 on the client side, and we can’t.
A big aspect to consider is also the « sexyness » for developers who want to join the project. It’s an important success factor for an open-source project 
The current tooling is aging and I think it’s important to update.
After that I don’t say the opposite! I agree with all the features you mention!
Normally this transco table is already done by the Z-Wave module itself! There are already huge tables in Open-Zwave that we use.
Since you have experience with other home automation systems, how do they do it on their side? Did they write their own transco tables in addition to Open-Zwave?
Gladys is independent of any technology. If there are adjustments to be made, it will be on the module side, never on the Gladys side! For Gladys a device is « abstract », it’s the module that makes the link with the real world
It’s planned!
Hello!
I’m not in agreement either 
SailsJS is still acceptable even though ExpressJS is twice as good in every way, but Angular 1… it’s starting to get old. On the client side, that puts us « just » four years behind in technology…
That’s another topic ^^
There’s no need for us to do the transcoding ourselves since Open Zwave already does it (and we use Open Zwave). However, it’s true that there is no type of DT for such functions in the core. So in this case, we could add a « select » type that would take the different items from the list and allow the user to choose in a fairly simple way.
What do you think @pierre-gilles?
Very good idea, I approve!
To be seen on the implementation side, the smartest way, it must not be a hassle to update.
Example: we realize afterwards that there is a typo in a JSON option, how to update in the DB for users who have already installed the module and created a deviceType automatically. To be seen if we store in the DB in the DeviceType as piznel said, or if we just make a special type and the module exposes a JSON… to be considered
haha never ask this kind of questions 
We haven’t even started thinking about v4, the reflection starts on December 21!
Then there is the design and finally the implementation. No scheduled date until we have the scope.
Amazon gives a little money I think if you have a product that works well with Alexa, I would check if we are eligible
Personally, I will only buy an Amazon device with Alexa if it’s compatible with Gladys and helps Gladys with voice recognition
I think a wait for this V4 would be that the modules of the V3 are V4 compatible. There are now quite a few modules (which have become indispensable!), I think we should not redevelop all these modules
All that is up to the modules to do, not the Gladys core ^^
It is therefore another subject 
Yes but it’s up to the modules to create the boxes as they need them ^^
Because we’re not going to put a box that manages heating in the Gladys core if it needs a module to work properly behind it..
Everything in the core must remain abstract and not require installing a module or anything. So if someone makes an RFPlayer module, it’s also up to them to make the box that will be installed with their module
Otherwise at this rate the list of available boxes will be huge and not everyone needs so many because not everyone has the same equipment!
And besides, before going through a box, you should use the Device and DeviceType API as much as possible.
But all these protocols should not be known by Gladys, it’s up to the module to handle it!
You can’t set the brightness this way for the moment but you can very well tell it to turn off and on (I also have Fibaro devices and it works very well for me)
Moreover, this has nothing to do with the Zwave protocol, it’s Gladys’ Brain that doesn’t know this feature
Not via voice but no problem asking Gladys for a certain % via script.
Well, I don’t know why, but last night my brain thought ONLY about Gladys v4, and I barely slept all night (I’m exhausted aha)
So this morning I woke up with a first vision of the data model, I put it on paper and I’m really happy with myself! It’s going to be amazing Gladys v4!
I need to type out a whole explanation of the changes I have in mind, and I’ll post it here. The idea is to give you a first vision, you challenge it based on your expectations, and that way when we meet in December we already have a debate to have and a basis for reflection.
But just to calm the topic a bit here, the goal is to talk about Gladys v4, not small changes/modules! Gladys v4 we’re talking first and foremost about major data model changes, we’re re-challenging the technologies used and the dependencies. We’re talking installation/migration/stability/installation of modules, that kind of thing above all
I’m waiting for the paving…
Likely next week, I prefer to think about it a bit with a clear head this weekend, and write a good long post next week!
It’s almost the weekend for me 
So far, I’m at 6 pages on Google Drive…
Stay tuned 
Should we meet informally on the 20th or the 21st?
I can do both! So definitely the 20!
That suits me even better in 20 days!
Any time works for me… 
What time works for everyone else?
Anything is fine for me too ^^
On the 20th, this forces me to come to Paris a day earlier, so to be honest, the afternoon is better, it means I take the road in the morning rather than on Wednesday evening.