By the way, a small remark, I see that you took inspiration from my integration view code, which is not necessarily good 
I am still in the exploration phase for some mechanisms, for example I see that you created two functions here:
const removeScene = (scene) => () => remove(scene);
const editScene = (scene) => () => edit(scene);
I know that’s how I did it in integration, but it’s not best practice! It creates new functions on each component render and thus slows down the app
Completely agree! But I was imagining a small popup that opens to the side ^^
I’m afraid that with a lot of information, it becomes tedious to read..
Yes yes I know, and I tried many other things to avoid it, but I gave up and thought we could change it later 
Well, however, I created a branch and committed to the repo thinking it was my fork 
Sorry… but at least you have the files
Ok! I’ve looked at that, it’s cool to see how intuitively you’ve developed it. It makes me think that before we start working as a group, I absolutely must write some guidelines so that we have the same processes for developing new routes 
I’m not talking about the code style, which is already enforced by ESLint, but about development methods.
An example:
I see that to change the route to the edit route, you created a function « Edit »:
edit(state, scene) {
const name = scene.name.replace(/[^A-Z0-9]/ig, '_').toLowerCase();
store.setState({
sceneEditing: scene
});
route(`/dashboard/scene/edit/${name}`);
},
We should avoid this, because if we access the route directly by entering the URL, the state won’t be present! Here a <Link> is sufficient.
By the way, the GET route /scene will probably only return a list of scenes with just the name, the id, and the selector. It’s the edit view that, when it loads, will fetch the entire scene!
Yes, I realized that
But as I’m not yet familiar enough with Preact (and these frameworks in general), I went for the simplest solution for now.
That’s what I wanted to do at first, but again, I went for the simplest solution 
No worries As I was saying, everything in the architecture of the current Preact project is not yet clear in my head either, I’m still experimenting on some subjects! We are still very far from being in the « industrial development » phase on Gladys 4, it’s still a lot of experience on my side.
I just integrated your design, it’s cool it looks good →
By the way, I added a « Trigger » tab to manage the list of triggers. My opinion on this is that it’s clearly something separate from the scenes, since it’s also a whole complexity.
We will have to think about how we model the trigger + the conditions.
For the scene editing view, for now I prefer the one I made, after that I agree we can work to reduce the space each action takes.
To go back to the subject of the Philips Hue service, I finished a first very rough version of this service (on the server side at least, the interface is not yet 100% functional).
All the service code is here.
The tests are here.
An interesting function of this service is the light.turnOn function.
I tried to do something as simple as possible, and by giving the service the minimum to do.
I deliberately did not do the entire gladys-hue service, as I am still experimenting, if we find things to change I prefer to have to modify only a few functions rather than the entire API
I will continue to think about other « classic » services, in order to get my hands on it and see if this implementation makes sense!
Wow, that’s beautiful, guys!!!
I’m reading your messages carefully to soak up some knowledge… Maybe it will come in handy one day when I have the motivation to dive into it…
Hello everyone!
Today I worked on 2 topics, the first is MQTT.
I defined the MQTT API specification for Gladys 4:
https://gladys-4-docs.gladysassistant.com/en/development#mqtt
Feel free to give me your feedback before I start the implementation
The other topic is managing the polling of certain types of devices.
Let me explain.
Some devices like Philips Hue have methods to refresh the state of the bulbs, in case the state was changed outside of Gladys, for example via a switch.
Until now, it was the module that managed the polling.
Now, it’s integrated into Gladys.
Each device has 2 attributes: « should_poll » and « poll_frequency », and Gladys will automatically periodically request the service via a « poll » method to ask it to update the state of a given device.
Interesting little statistics, the most frequent searches on the forum in the last few months!
No surprise, it confirms people’s interest in home automation in 2019.
In short, we are heading in the right direction! 
Xiaomi had to be included!
I hope it’s part of the base equipment in Gladys 4
I will need the help of @piznel to migrate his excellent module, but yes, that’s the goal!
Xiaomi is in the mandatory services for v4, no debate about that.
This is going to be complicated… @piznel is offline for a while!
What’s up with piznel? Did I miss an episode?
Well, I just created a fairly exhaustive list of the remaining tasks to be done before having a first minimal functional version of the Gladys 4 backend.
https://github.com/GladysAssistant/gladys-4-playground/milestone/1
This milestone does not include:
I created this milestone to list all the remaining tasks to be done (both code and documentation) before we can work on the services.
The frontend will continue to be developed in parallel, even if for now my personal focus is on the API.
Ouch, what a shame, are we talking about days/months/years? Well, we’ll manage
Personal reasons but he’s fine, and no you didn’t miss an episode ^^
No idea! But I’d say a few months given the latest news 
I saw your list @pierre-gilles, so I received the 40 or so emails this morning
But why in each route do you put v1? Are you planning to version the APIs?
If you want, I can do a few things to save you time! Just tell me what you want me to do. For example, I noticed that the drawer doesn’t work on mobile, I can fix that?
Anyway, I can do small things like that while you properly define the guidelines?
Another thing, I built the V1 branch of tabler and I realized that the entire template was redone from scratch and a lot of things have changed! So I wonder if it wouldn’t be better to start from this version even if it’s not yet fully complete rather than having to redo most of the work in two or three months when they finally release V1?
aha sorry for the spam, I went all out
Yes! The API is versioned. If we start to have mobile apps, external services that depend on it, we can’t afford to break the API. So if we ever change the response format of an API, we keep the v1 route, and we create a v2, simple as that
Mm the drawer I’d say don’t bother, it works on the gateway, I just need to take back the code that does that :slight_smile
However, I would appreciate help with frontend questions, like the other day with the scene view, it really helped Since we’re not really ready in terms of frontend guidelines, don’t bother too much with the code, just some small design tips would help me a lot, CSS is my weak point ^^
A few ideas:
1/ For the chat view, I struggled to recreate a chat and I’m not very satisfied with the result because the chat bubbles are not proportional to the text size. I think we just need to take back the CSS from Gladys 3 which was great (maybe adding the avatars, since in Gladys 4 a user will have an avatar + Gladys now has a logo!).
2/ If you see a way to reduce the size of the « scene editing » view. I agree that it’s too big right now. After that, I want to keep clarity and ease of use, it needs to stay airy!
3/ I haven’t thought about the « trigger editing » view at all
Oh damn, the CSS changed completely?
We need to evaluate when they plan to release. I’m not necessarily for switching to the v1 branch if they are still actively working on it, the current version is more than enough for what we do! After all, if they release v1 in 2 weeks, okay ^^
For those who follow me on GitHub, I’m currently working hard on the Backend of Gladys 4, I’m making good progress in milestone 1 
In the last few days I’ve worked on:
Hello everyone!
Small Gladys 4 progress update
Backend first milestone progress
The backend v0.1 milestone is progressing well, we’re at 54% of tasks completed. I added a few todos along the way, but I think once all the tasks are done we’ll already have a minimal backend that does the job.
REST API documentation online
I just hosted the Gladys 4 REST API documentation online:
https://gladys-4-apidoc.gladysassistant.com/
Feel free to check it out and criticize some naming choices, or parameters passed to API routes, as nothing has been released yet we can still change everything. It’s always cool to have outside opinions
Scripts in Gladys 4
I have a small question for you regarding scripts in Gladys 4.
In terms of interface, I was wondering if it was worth having a separate script tab from scenes.
Couldn’t a script in Gladys 4 just be an action in a scene that says « execute this piece of JS code »?
The Pros
The Cons
Tell me your opinion on the question, it’s a debate nothing is set in stone yet!
I agree with you except when you just want to run it alone manually to test something quickly, it’s still convenient to have it in a separate list.
We’ll see if the same thing is possible in the scene section…
Indeed! The goal of the script editor in Gladys is that it is comprehensive enough to be able to code properly in it…
That’s the goal!
Gladys 4 is a complete rewrite, there is no common code between the two codebases. It’s a completely new product Given the changes, it will necessarily be a reinstallation (we are completely changing the technology and deployment process). However, we will probably provide a migration tool to recover some data
To be seen, what data we want to transfer from V3 to V4. Not everything is worth keeping, and we don’t want it to create mysterious bugs due to poorly formatted data from V3.
It’s the same for scenes! That’s the purpose of scenes, you can click on « play » and it plays the scene.
