@OrTiN the shutter module was missing (not in the package). I published a new version 0.2.17
-
Thx, gBridge now working again.
I got a message that no rolling time is configured :
Error getting devices: Error: No rolling time configured.
I am using the shellShutter device for my Shelly’s. RollingTime is not available there. -
I wrote a script which handles up/down/0-100.
The call for 50% would look like this:
sh /home/user/subfolder/script.sh $mode $room 50
Within the script the specific shelly command is:http://192.168.x.x/roller/0?go=to_pos&roller_pos=50
-
@ortin so your shutters support position commands. How do you configure the ShellShutter for the position command. Is that the ‘getPositionCommand’? I don’t see a ‘setPositionCommand’
-
Currently I run the shutters over the UI up and down only. States between must be stopped manually. Via rules I run to special positions to realize sun protection for example. The state and position will be detected via “getPositionCommand” every 60s only. Yeah it pretty long intervall, but I had also tested it with 1000ms interval, but the CPU went over 70% after I configured it for my 8 devices.
My script is very lightweight. I use curl to get the state which comes in json format and piping all the stuff to get to the values “up/down/stop” and “currentPosition”. The stop command releases the buttons on the UI and the currentPositions are written in a modul related variable in pimatic. Maybe too much for my VM…
I have to extend it to get the state only during shutters are running. It planned to go for it at the weekend. Then the intervall could be much shorter.What would be nice is to define a command in the gBridge device which will be extended by the GA return value.
For example I say: “Hey Google, shutter bla 50%”. GA will set the shutter to 50 in the cloud. This value could be read back and then extend a pre defined command in the gBridge shutter sub device.
With pre defined command I meansh /home/user/subfolder/script.sh mode room $readBackValue
orhttp://192.168.x.x/roller/0?go=to_pos&roller_pos=$readBackValue
or what ever the user defines.Just a fast example:
-
@ortin thanks for the insights.
I would like the device config to be as generic as possible.
I will introduce a generic aux of that will be used if an adapter has specific needs.For the shutter it will be the position shell command. The position value (0-100) will be added by the plugin with a space at the end of the aux field.
The getPositionCommand of the ShellShutter gives only ‘moving type’ status: ‘up’, ‘down’ or ‘stopped’ and not a % position! The position value will be hold in the plugin-adapter. GA will get that info when GA askes for status. In Pimatic this value is not visible. You can see of course the shutters position when you look …
On startup the position sync is still an issue. But when the shutters are fully opened or closed, its easy to sync the position (if there’s an auto stop safety).
If your script returns the real position, that could also be used as the position value -
Sure, was just a brain stroming from my side
I like your generic aux approach! Regarding position determination. What about an optional, interval triggered
auxGetValue
command option beside the general aux. This value could handle the position sync issue with GA if, let us stick with the example shutters where controlled by UI or old school via wall switch? -
@ortin i just released a version with one aux command line. The result value of that command is used as position value. If you extend your script with the position as result value, this would work.
You could also change your function into moveByPercentage, with a maximum value from -100 (fully down) to 100 (fully up). You always return the resulting position.
When you ask for moveByPercentage 0, you only return the current position.
The absolute position getting from GA is translated in the plugin to the relative position for the shutter.
Let me know if this is an option for you, so it can change the adapter -
Okay, first test lets my test shutter dancing behind me. Nice work! Thx for this!!! I tested commands like "open shutter, close shutter, set shutter to 25%… All works!
I see currently GA doesn’t shows position. Maybe this will come in future. This was my idea behind the separate “getAusValue” which could be interesting btw for temperature response as well. If some value change independently from GA, GA will be updated continuously.
The aux option opens the door for many new goodies !
—EDIT—
I forgot to say that I extend my script in that way, that it returns now a json format return value like
{"status":"stop","position":"15"}
. -
The simply call of my script return the Shelly standard response like:
{ "state": "open", "power": 0.0, "is_valid": true, "safety_switch": false, "overtemperature": false, "stop_reason": "normal", "last_direction": "close", "current_pos": 10, "calibrating": false, "positioning": true }
Is a little bit more as only the number. But it works! The above mentions return value (
{"status":"stop","position":"15"}
) is the value which returns when I ask explicit only for the status of a shutter. Somehow you are handle it in the right way. -
@ortin the return value is used to update the actual position when GA ask for the status.
But it looks like that part of GA and gBridge isn’t working.
Its better is use the right return value. I will make an update that can handle both return json’s -
Still works like a charm!
-
Hi Bert, awesome job creating this plugin!
I’m using pimatic-milight-reloaded for my lights and so far I can turn them on/off and change the brightness.
Would it be possible to also integrate RGB color switching?Another thing I would like to request is the control of the DummyHeatingThermostat.
-
@jarnoglenn thanks.
I will look into your request, but first I am going to ski the coming week in Austria -
The plans changed a bit, skiing is for later this year.
@jarnoglenn I added the color option for Milight to the plugin (not published)
Which of the 4 Milight devices are you using?
The gBridge API doesn’t support yet automatic adding of color features via the API.
So if you want to use color management you need to add the color control via the gBridge device management portal (where also the API key can be obtained).
It’s not very complex. For your current Milight device you just add the Color Setting(RGB) trait (besides OnOff and Brightness). The new version of the plugin will than support color.
Let me know if that is workable for you, else we need to wait for gBridge to upgrade the API -
@bertreb I’m using MilightRGBWZone and MilightFullColorzone.
I already figured out I have to manually activate the color control and automatic adding is not a priority for me.
I assumed the color values (html colors or rgb values) are passed but the plugin doesn’t know what to do with it because the function does not yet exist.So if you can make it so the values are passed through to the light plugin i would already be really happy!
-
Sometimes I’m just a total nitwit so I’m afraid I need some basic help:
For some reason I cannot connect to the gbridge mqtt server.
“MQTT server Connection refused, not authorized”Only thing I can think of is the tls certificate? Installed the plugin through the GUI, created an API key, copied it to the right place, left everything default except the mqtt username (gbridge-u***) and mqtt password.
Sorry for this dumb question, I guess I’m overlooking something…