Now that’s something else! I’m excited about being able to add offsets to events (-1h/+1h).
In the case of the sun, it could be a scenario like:
{
"type": "sunset",
"offset": "-01:00:00"
}
I think Home Assistant does this!
Now that’s something else! I’m excited about being able to add offsets to events (-1h/+1h).
In the case of the sun, it could be a scenario like:
{
"type": "sunset",
"offset": "-01:00:00"
}
I think Home Assistant does this!
A fond typically turns on your lights before sunset
The use is isolated and specific. If phpmyadmin is needed, it means something is missing in Gladys.
Moreover, it adds support and there is no need for phpmyadmin to edit the db. Mysql workbench does the job and is cross-platform.
Already, Gladys 4 will be primarily based on SQLite, so it will be different
And yes, I agree with @VonOx, Gladys 4 aims to be a product usable by everyone. If we have to play in the DB to use it, we’ve missed something..
It’s planned! In Gladys 4, there will be a home alarm system (armed/disarmed), and I’ve planned for it to be via a code on a numeric keypad so that it’s easy to unlock on a small tablet placed at the entrance/physical keyboard + Arduino ![]()
Mmm, I’m less sure about that, to be precise I think it’s not even possible to do that technically since the Gladys Gateway is end-to-end encrypted so I have no idea what is transiting through the server, it’s your data! But thanks for the suggestion, it’s always good to have feedback ![]()
Hello,
I have a small question, but I’m not sure if it’s related to V4 or not.
I’ve been playing around with gladys for some time now, and at first, I was creating scenarios like:
Coming home at night
Turn on entrance, turn on living room, etc.
Leaving home
Turn off light X, Y, Z
But then, I realized that I had a lot of scenarios that affected the same device to put it in the same state, like when I go to bed and leave the house, turn off all devices.
So, I thought maybe do it another way: create scripts like:
Etc.
So, in terms of scenarios, you just have to call a script and that’s it.
Similarly, for scenario evolution to integrate a device or other, you just have to modify the scripts.
In V4, I imagine yes, but are there any changes planned for scenarios/scripts?
Is the scenario method that calls scripts a « good » method to configure gladys?
And a small bonus question, do you have a date in mind when you would like to finish V4? ![]()
I just thought of a case where disabling/enabling scenarios could be useful.
I am on call every third week. So I have a scenario with a CRON alarm that tells me every night at 10 PM that the on-call duty is over. But this scenario is only useful to me one week out of three.
So far, as soon as the on-call duty is removed, I delete the scenario, and I add it back when I am on call again.
Enabling/disabling the scenario could be useful in this case ![]()
Hello everyone! ![]()
I’m coming back to the lighting part. To propose new features and improvements, I’m basing myself on the Awox module by @AlexTrovato, which he is currently improving to integrate the Bluetooth Mesh bulbs of the brand. These bulbs have 3 main modes:
We can control the following parameters on these bulbs:
This makes a lot of parameters.
And on the local Gladys IHM and Gateway, it’s not always practical to have so many controls at the same time.
Here are my proposals:
It would allow switching between modes, in our example: Colors/Sequence/White.
We could give it a triangular shape, it would be nice, but it would take up space. Otherwise, we can do it horizontally, with a pictogram in each state (ex: Colors, Warm/Cold White)
(o)–o–o | o–(o)–o | o–o–(o)
(I’ll add some images a bit later)
The possibility to dynamically hide controls depending on the state of another, here: disable the color controls when in White mode.
Ideally, the hiding of controls would be configurable, so that those who wish to always display everything can keep them all.
Each brand controls the color of its bulb differently, some use RGB (RGB) directly, others use HSL (HSL).
From a user’s point of view, we more often want to change the hue of the bulb than to set the color in RGB.
I therefore propose that we have a color picker that is by default in HSL, but that we can also use in RGB.
When we want to change the color of the bulb, by default, we would only see one seekbar (the hue) and we could display the saturation with a button, but also switch to RGB with another button. The brightness, on the other hand, can be managed directly with the corresponding seekbar, no need for redundancy.
Then, Gladys would take care of calculating the color as the bulb module needs it, whether it’s in 8 or 16 bits, or in percentage, with RGB or HSL values.
Currently, the controls (buttons, seekbar…) do not have a « action in progress » status for devices with status feedback. Ideally, we could add an animation (small circles rotating in the button point for example) to remedy this. If the action is not done (timeout), we can have a slight red flashing of the outline before the control resumes its previous state. Or if it retries several times (param: retry X times) the outline would be orange.
In short, all this to say that in terms of user experience, nothing should be left to chance. When the system performs an action and is processing, the user must « see » it!
What do you think? ![]()
No but that will be possible anyway
Having an activated/deactivated scenario is basic in the UI!
Here we were talking about the possibility of activating/deactivating a scenario within the actions of a scenario (it’s a bit meta :p)
Great feedback ![]()
Actually, what we had discussed during the developer meetup was that in certain specific cases, we could create specific deviceFeature types for certain devices that have really very specific behaviors.
Attention: Each case must be evaluated with great care to ensure that we do not add hyper-specific buttons and that in the end we do the opposite of what Gladys should do: unify behaviors between manufacturers.
So, I have a hard time seeing how in your case, these bulbs have such specific behaviors!
Apart from the sequences (which there can indeed be a specific button), the rest is like the Philips Hue, right? Granted, the formats are not the same, but they do exactly the same thing as Philips Hue, right?
I’m not necessarily in agreement on this! Even when your lamp is in white, you might want to turn your bulbs yellow/red suddenly to dim?
For the color picker, we were talking about it earlier in this discussion
The idea is indeed to unify the color behavior between bulb brands, it will be the same for everyone!
100% in agreement on this!
Hello @pierre-gilles!
I had some time to kill at work this week, so I did some research about the scene editor’s UI.
So I was heavily inspired by Homey’s « Flows ». For those who don’t know, Homey is a home automation system designed by the company Athom, and it’s horribly expensive (that’s actually why they’re not emerging).
Even if they don’t manage scenes as complex as Gladys 4, their UI approach is very friendly. So I wrote a quite complex scene to push the reflection starting from their horizontal and card-based approach.
To see what I’m talking about, here’s a typical example from them:
{
"name": "Wake Up Tony",
"selector": "wake - up - tony",
"decscription": "Scene when user tony wake up.",
"actions": [{
"type": "devicetype.turn-on",
"selector": "room.bedroom.light.binary",
"value": 1,
"then": [{
"type": "delay",
"duration_in_seconds": 10,
"then": [{
"type": "speak",
"selector": "room.bedroom.pod",
"text": "Hello Tony!",
"then": [{
"if": {
"type": "sun.sunrise",
"selector": "house.malibu-house",
"so": [{
"type": "rolling-shutter.open",
"selector": "room.all.rolling-shutter.open",
"value": "open"
},
{
"type": "devicetype.turn-off",
"selector": "room.bedroom.light.binary",
"value": 0
},
{
"type": "speak",
"selector": "room.bedroom.pod",
"text": "In Malibu it is 22 degrees, the sky is slightly overcast. The weather is ideal for surfing."
}]
},
"type": "dashboard.display",
"selector": "dashboard.portable",
"data": "{day}, {hour}, {weather}, {armor.state}, {armor.manufacturing.state}, {calendar.day}, {stock-market.stark-industries}"
}]
},
{
"type": "music.play",
"selector": "room.all.harman-kardon",
"value": "playlist-yyyy"
}]
}],
"type": "devicetype.set-value",
"selector": "room.bathroom.shower.multilevel",
"value": 26,
"then": [{
"type": "speak",
"selector": "room.bedroom.pod",
"text": "Your shower is ready",
"then": [{
"type": "devicetype.turn-on",
"selector": "room.bathroom.light.binary",
"value": 1
}],
"then": [{
"type": "delay",
"duration_in_minutes": 20,
"then": [{
"type": "devicetype.turn-on",
"selector": "room.kitchen.coffee-machine.binary",
"value": 1,
"then": [{
"type": "speak",
"selector": "room.bathroom.pod",
"text": "I put your coffee to heat sir"
}]
}]
}]
}]
}]
}
This is typically the kind of scenario I have at home with Gladys 3 currently ![]()
I did some drawings on paper but as I’m a poor drawer, I made some drafts to illustrate my ideas as best as possible!
As you can see, I took most of Homey but modified the structure to adapt it to scenes much more complex than Gladys 4 will be able to manage. (Maybe it lacks a bit of color) I specify that these are just mockups and that it’s done quickly ![]()
All suggestions are welcome! ![]()
I also tried a vertical approach on paper but when I started making the mockups, I gave up right away because you drastically lose readability. This is due to the restricted width imposed by the template used in Gladys 4.
Hello @MathieuA!
Top tout ça, super réflexion.
Aha tu vas rire, j’ai une note sur mon ordi avec des inspirations d’autres systèmes, j’avais quasi le même screenshot ![]()
I like the fact that each scene is a card, I think it’s the best approach to fit as many scenes as possible while remaining visual and clean.
It’s nice that you can launch the scene from the scene list, it’s clean!
Two modifications I would make:
It’s really clean! GG!
Would you see how the modification inside an action? For example, if I want to set the wait time?
Did you do all this in HTML or is it just a mockup?
Hi,
I’m coming back to this part:
I think it would be useful to be able to « disable » a control (without actually hiding it). It happens that the device is not reachable, and the module could disable the controller to indicate the absence of the device.
For example, in the case of connected bulbs, when I press the physical switch of the lamp, the bluetooth is no longer powered, the bulb is no longer available: disable the button on the Gladys interface to indicate the unavailability.
I may not be clear, but I understand myself ![]()
I see! Not bad, that makes sense in many integrations
I’ll note that
Hello everyone!
Quick update on my developments ![]()
1/ A first module poc well advanced
Today I worked on developing a first light management module, the Philips Hue module. It serves as a basis for me to experiment with the API and code a module from end to end, including tests.
The goal is for even the modules to be covered 100% by tests. To do this, all calls to external libraries are mocked using proxyquire.
To see the next-gen philips-hue service, it’s here →
https://github.com/GladysAssistant/gladys-4-playground/tree/master/server/services/philips-hue
The philips-hue module tests are here →
https://github.com/GladysAssistant/gladys-4-playground/tree/master/server/test/services/philips-hue
Feel free to give feedback, nothing is set in stone ![]()
2/ An online demo frontend
Yes, thanks to the fact that the Gladys 4 frontend is now a PWA completely separate from the backend, this allows me to host an online demo version of Gladys, which is deployed with each master merge thanks to Netlify automatically. 100% transparent for me, no maintenance to do.
It took me 2 minutes to set up, and honestly it’s great!
The Gladys 4 demo frontend is available here →
Note: this is 100% of the work in progress, so very few things are functional today, but the advantage is that now I can more easily ask you for UI feedback, without necessarily having to deploy a local Gladys. Pretty cool, huh?! ![]()
For information, I put a demo mode in the frontend: all HTTP calls are not made on Gladys (because in demo it’s just the frontend running in static), but just on a static JSON file that has demo responses so that the UI renders well ![]()
It’s very simple, but it’s only thanks to the new Gladys architecture that I can launch this kind of thing so easily. I can’t imagine the complexity of hosting a static demo Gladys with v3…
In terms of UI, I think the ability to arrange the blocks yourself, either directly via drag’n drop, or in the settings would be great.
Preference for drag’n drop, I have a bit of trouble with the current management and order numbers (or else it would be possible to edit them to rearrange them easily and not delete everything to redo an order)
I don’t know if this comment is in the right place here, I throw it out, you can throw the stones.
Edit: missing a capital N in « navigation » in « integrations »
Hello!
Great minds think alike ![]()
I’ve had the same thought and ultimately left it as is, mostly out of laziness to re-modify everything ![]()
But if you want, I can try when I have some time to kill to see what it looks like!
Haha well spotted! It’s a criticism I’ve often made of Gladys 3 as well! I admit that on the spot I didn’t think about it ![]()
The FAB makes more sense to me, especially since it’s becoming more popular. I think it’s an excellent idea in the sense that we can modify its shape, its location, and above all use it in several views at once.
It could even become multifunctional to lighten the UI!
Example: The FAB itself allows you to create a scene, but if you select multiple scenes, the FAB opens an action menu to, for example, delete all selected scenes or even export them to a JSON or something else ![]()
The applications of the FAB are multiple and can be very practical! It’s just a matter of reflection, but it’s not exclusive to Android even if it’s for Android that Google created it ^^
I thought of a small popup that opens next to it when you click on it. I haven’t pushed the reflection on this I admit.
These are just mockups ![]()
GG for your progress ![]()
Are you talking about the dashboard? Absolutely it will be the case! For now, the dashboard has not been coded at all, it’s just a pure copy and paste from the gateway, static, nothing is done ^^
As I was saying in the manifesto, the dashboard will be 100% customizable, with custom blocks. And indeed, I want it to be drag and drop, probably via an edit mode (to be defined)
Well spotted ![]()
Don’t bother, we see the idea.
Right now, I’m going to need help with the HTML implementation of all this, me who is not a big fan of CSS, I’m going to need help ![]()
If anyone wants to lend a hand, don’t hesitate ^^
My goals for the day are to continue my work on the Philips Hue service and to have ASAP a fully functional end-to-end demo, that is to say:
For my part, I just tested Preact on a small project and it seems great. I’d be happy to help but I prefer that we tell me concretely what could be interesting to do. Like giving me a task (making the bidule module, etc). I like both front and back end
I’m not difficult ahah
So I don’t know if there’s a Trello where we can assign work to people?
Thanks ![]()
No Trello for now. At the moment, I don’t think the project is in a state to work on it in an assembly line mode, but it will come. I prefer to properly define the basics, I’m still experimenting with everything related to folder architecture, class structure, event flow, and data model.
As soon as I have the project working end-to-end for each type of module, then yes, I will need help to migrate the Gladys 3 modules to Gladys 4
I think I will put all the tasks in GitHub issues, and we will close them one by one ![]()
But before switching to « industrial » mode, I will make the documentation so that it’s easy to contribute and to be consistent across the entire project.
Here I was just asking for a little CSS help for the scene view of the frontend, nothing bad ![]()
Hey @MathieuA, I log in to Twitter and boom, I see a great inspiration!
It looks a lot like what you’ve done, it confirms that we wouldn’t be the only ones ![]()
(the links between each task are fixed, it’s just to make it clear, nothing to do with the tangled knots of some scenario interfaces of certain editors)
Oh, I see! Honestly, I leave CSS to others ![]()
I’m more into using something that already exists and tweaking it a little. I’m looking forward to it!