How about this afternoon then! How about 2:00 PM in Paris? (I’ll look for a place like a library/café) where it’s easy to work
Perfect for me! I’ll probably be there a bit earlier then ^^
Oh really @pierre-gilles! Have you finished your book on the V4?
I suddenly feel like reading 
It’s still in progress! 9-10 pages so far! 
But I have a lot on my plate right now, very busy week for me. I had the Domadoo interview yesterday, it took me time to write the article. And I’m setting up my first freelance mission for December so I can keep paying my rent 
Because in the end I said I was doing part-time Gladys, but in the end I did full-time Gladys for 4 months there!! ^^
I think I’ll take the weekend because I’m dead, I’m trying to make progress on the subject next week
You need to take care of yourself or you’ll crash mid-flight 
It’s not yet certain that I can come on Thursday, I’m still advocating for it
I’m posting here the link to the Gdoc for archiving →
This weekend, I started integrating my new thermostatic valves into Gladys.
I realized that the deviceType system did not meet this need.
Let me explain.
My valve is in a room, I need to define for it:
- the setpoint mode (temperature or percentage)
- the desired value (in temperature or percentage as a fact)
- if I use an external control (i.e., a temperature sensor located in the room)
- the value of this sensor if defined, when the latter is updated
Every change, I have to send back all its configuration.
Apart from playing with user parameters, I cannot control this equipment properly, I would probably need a configuration page specific to this type of device.
Moreover, I can send it the following commands:
- switch to summer mode
- switch to maintenance for removal
- reactivation
And I can receive many states, I can manage all this via X deviceType (which I have started to do) but it is not simple, knowing that for the deviceType, globally I always have to receive an integer, it’s not great to parse to see clearly.
Should this be on the table for V4?
Hello everyone!
I’m confirming with all of you for 2:00 PM this Thursday in Paris!
You can reply those who are coming, I will create a private channel to define the location!
I’m in! (And @piznel too) 
I will be there too!
Hi guys!
So, was this meeting productive?
(I can feel you must be fired up! 
)
Hello @Retlaw!
Yes, it was very productive and very enriching! And if another meeting needs to happen, I’ll be there ^^
Personally, I’m super excited!! Especially since we talked about a lot of things! UI, DB, API, in short, a bit of everything and especially the vision we wanted for this V4, and it’s promising big things 
Yeah, it was great, PG confirmed a V4 release on January 2
attention this message contains fake news!
It might be cool to rebroadcast it on Twitch for those who can’t be present 
Indeed, super productive Now the next step is to finalize the data model we designed all afternoon!
But for now, it’s time for the end-of-year celebrations! An opportunity to see family, friends, and take a breather from this intense year 2018
Hello everyone!
I just put on paper the data model of the devices we did with @MathieuA and @Jean-Philippe in December.
This is only the device part for now, the rest will come.
To add some explanations:
- selector: these are the smart selectors I was talking about in the manifest
- internal_id: The identifier today
- Pod: a Gladys pod, in short a machine running the pod version of Gladys and therefore remote modules
If you have any comments/questions, I’m interested!
Yes, I have a comment @pierre-gilles
You have the name field twice in the device table and so is the module missing too? 
I don’t remember what we said I admit.
Module is a separate table, so there is a relationship but we don’t display the attribute in the UML modeling!
But yes, it’s included!
Good catch for name 
Ok, I suspected as much, but I still made the remark just in case ^^
We’ve talked about this topic for hours
From what I remember, we thought it was a mistake to store them in the DB because it was a nightmare to manage for internationalization and updating these values in case they change.
Our opinion:
For some very specific devices (you’re talking about the famous eco/freeze mode, etc., or the Xiaomi button with 4 modes), well, we will need to create specific types that in the UI will derive from a specific button. Thus, we can manage the « look » of the buttons more finely, internationalization, because in the end each case is very specific and I don’t think it’s worth making it generic.