@AlexTrovato we can discuss this here in French because I feel like weâre not understanding each other in English over there
Actually, the problem is storing information about the roller shutterâs capabilities.
Letâs imagine three hypothetical shutter brands:
The first is controlled by a remote with 3 buttons: open the shutters to 100%, open to 50%, and open to 0% (closed position)
The second is controlled by a remote with an up button and a down button.
The third is controlled by a remote with 5 buttons: 0%, 25%, 50%, 75%, 100%
Question:
How to model this in Gladys?
When I say « this, » itâs not the final result, yes the final result could be an integer from 0 to 100 that corresponds to the shutterâs opening percentage, Iâm talking about the information that will say « this roller shutter has this functionality »
Because in the UI, each shutter will have a different type of button, but there must be somewhere in the DB this information
One possibility I see is to handle it case by case, we create category/type pairs for each type of shutter. I think this is the solution closest to the philosophy of Gladys 4
But there may be other ways to do it, and especially to see how this question could apply to other issues.
I hope you see what I mean Good idea anyway to look at how others do it!
Ok, I understand better.
At first glance, I would say to have a device category for « shutter system ». But that might be a bit heavy.
Thinking carefully that this will concern several types of devices.
Otherwise, a « param / options » system on the device feature.
So, would a roller shutter have a single device_feature? And this device_feature would have the category + type corresponding to its use, and we would store in the state an integer from 0 to 100 corresponding to the shutter level? That could work.
Itâs true that it might be a bit heavy, but I prefer this initial approach as long as we donât have too much experience with roller shutters, rather than starting with the ultra-modular approach without understanding and making a mess
I prefer to go from ultra-specific to general rather than the opposite.
A question that comes to my mind is how to explain in the UI in the MQTT service what each feature corresponds to? Since we only display the name, the name must be explicit enough to explain « so this feature corresponds to the shutter at 0, 50, 100% » ^^ any ideas?
Hello,
Indeed, itâs often like this, with a learning phase.
The problem with this principle is that the ascent/descent times are not necessarily the same.
The descent is faster than the ascent because the mass of the VR pulls it down.
However, itâs a matter of very little.
In Domoticz, there is a Motor Operation Time parameter.
This is what I have at home and it is the most common from a manual switch point of view (switch models).
Moreover, there are models of connected switches (4th gen+) that manage the percentage of opening from a timer.
The idea is to provide the ascent/descent times and then, depending on these times and the direction of the command, partially open/close the shutter.
In the application, there are 2 types of commands (up/stop/down and slider):
I developed a small ESP8266 assembly to manage shutters with a 3-position inter or via Gladys. Initially, I initialize the up and down times. I send the position in % with each change in the shutter state. (on my assembly itâs inverted 100% is closed - 0% open)
I think itâs not Gladysâs job to calculate the position of the shutter but the inter to return the position.
Example:
I request via Gladys to open the shutter to 25% but I decide, given the sunshine, to stop it at 50% using the wall inter.
I press the stop button.
By the time Gladys receives the stop information, Gladysâs calculation will be wrong.
There will be a discrepancy between the actual position and the position estimated by Gladys.
For 9 months the subject has not moved, are you still looking for a solution?
At jeedom itâs simple Up/Stop/Down, the percentage does not work well so not integrated by default! indeed the percentage is calculated based on the time the shutter will take to travel from one point to another ⊠except that all shutters are different even if used with the same engine.
I may not have understood what this function is stuck on?
Just a matter of time, I think. On my side, over the past 9 months, I have focused on the most requested features (multi-users, multi-dashboard, scenes, zones, presence, Google Home integration, well, all the devs of this year 2021, you know :D). Since this feature only had 2 votes, it was necessarily less of a priority
After that, Iâm always open to discussion if someone wants to take over a reflection/development.
Yes, see if square outline âŠ
Is there a guideline for the icons? See a library?
For the skills, I have web development but no React and very little JS.
In short, I am a front-end developer with HTML/CSS/PHP. I saw that it looks a lot like Bootstrap for the front end, but I donât know if I have the time for it.
I assume there is a back end? I didnât see where everything is located for Gladys. (Itâs a shame we donât have a doc with the file structure)
After that, the best thing is to launch an instance locally, you have all the front end in the « front » folder, and all the back end in the « server » folder (Itâs Node.js)
Nothing too complicated, and Iâm always here to lend a hand if you have trouble!
For those without feedback, it would be necessary to configure in Gladys:
a maximum time for full descent
a maximum time for partial descent (when you see the dashes)
a maximum time for full ascent
a time at 50% of partial ascent
a maximum time for partial ascent (when you see the dashes)
a time at 50% of partial descent
In terms of algorithm, this would result in:
Open to 100% = max full ascent time + 2s (to be adjusted) then reset position to 100%
Close to 100% = max full descent time + 2s (to be adjusted) then reset position to 0%
Starting from a full opening or closing, we always have an exact reset position
After that, if you want to open to X%, itâs the time at 50% plus or minus (time at 50% / 50) * the position to reach in % we get an approximate position that should be quite reliable, right?
Hello here,
is there any progress on the subject? Is it being processed by someone?
I see with the z2m service that the demand is increasing, with models with OPEN/STOP/CLOSE (3 actions).
@AlexTrovato As far as I know, no one is working on this topic.
In my opinion, thereâs nothing to lose by starting development for just one type of roller shutter (Open/Stop/Close for example, yes), no need to try to do everything, itâs already great to have one type.
Good idea anyway to look at how others do it!
