Because the switch is momentary due to the 1s expiry, I want to create a dummy switch that has 2 states that reflects the state of the Door Close Contact. So a switch to create the open/close command and the state of the switch is created by the feedback of the Garage closed contact. I mainly want this for Apple Home integration.
I also want to create something that with feedback 3 states - Closed, Travelling, Open - that reflects the status of the 2 contact sensors,
Ive tried this:
> //GARAGE DOOR STATE
>
> rule "Garage door opening"
>
> when
>
> Item GarageDoorCContact changed to OPEN //Door opening
>
> then
>
> GarageDoorCContact.postUpdate( "OPENING" )
>
> end
>
> rule "Garage door closing"
>
> when
>
> Item GarageDoorOContact changed to CLOSED //Door closing
>
> then
>
> GarageDoorOContact.postUpdate( "CLOSING" )
>
> end
>
> rule "Garage door closed"
>
> when
>
> Item GarageDoorCContact changed to CLOSED // Door closed
>
> then
>
> GarageDoorCContact.postUpdate( "CLOSED" )
>
> end
> rule "Garage door open"
>
> when
>
> Item GarageDoorOContact changed to OPEN //Door open
>
> then
>
> GarageDoorOContact.postUpdate( "OPEN" )
>
> end
But get the errors:
[WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert 'OPENING' to a state type which item 'GarageDoorCContact' accepts: [OpenClosedType, UnDefType].
[WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert 'CLOSING' to a state type which item 'GarageDoorOContact' accepts: [OpenClosedType, UnDefType].
A Contact Item can only have the states OPEN and CLOSED. OPENING and CLOSING are not valid states. You need to use a String Item to represent those states.
It depends on how that existing Contact Item is used. If you have it configured for persistence, it might break the database for that Item. At a minimum it will lose all the historic data associated with that Item as you can’t have a column in the database of two different types. If it is a member of a Group:Contact it might break the Group since it will no longer be a Contact Item.
But in general changing the type of an Item is no problem.
Hmm, I once had a problem changing item type. I think I sat a Dimmer for at Switch item (on/off). Either the binding or openhab (cant recall exactly), gave an error.
But I would assume, String would always be fine.
Probably the binding. Often it dictates what the Item Type can be to link to a given channel. Which raised a good point. @jay7210, you probably have to change the Channel type on the MQTT Channel linked to this item to a text type.
Actually, in a context to this thread, I have been thinking for quite some time, if it would be possible to somehow build a “Rollershutter” by the use of a rule and items.
Thing is, my garagedoor opener controls the door from a (one) push button… I recall you´d mentioned, thats the typical way to control a garagedoor, Rich?
Now, in order to use the updated GA integration, the garagedoor would need to be of rollershutter item type.
But what would prevent me for making a “software” rollershutter… I have the push button, and I have sensors for door open and door closed (top/bottom sensor). What I dont have is the interval 0-100%. But I doubt thats really needed for rollershutter, (I could be wrong on this though).
Every garage door opener I’ve ever seen works that way. When I say that the new GA integration treated it as a Rollershutter I figured maybe in Europe they work differently.
Yep. The Rollershutter Item actually store’s it’s state as a PercentType. And when you issue a command to it it get’s sent as a number, not a discrete event. To get it to work as expected, I think you would need to deal with the numbers. If you have the state machine properly set up so you know when the door is opening and closing, you could use timing to estimate the percent open of the door and the icon should end up working right. Just remember to recalibrate the percent when the open/closed sensors indicate the door is fully open/closed.
You will also need to handle in some way commands to “open the garage door to 50%”. You may just ignore them but they will be valid commands that need to be handled.
I’m pretty sure this could be done, I’ve seen similar for not do smart rollershuttters, but it’s not super easy. If you didn’t have sensor to tell you when the door is fully open or closed it would be much more difficult.
Anyway, give it a try. Even if it doesn’t work you will learn something and that makes it worth while.
No, not as far as I know…
I know there are some “smart” openers, which have two states (or two buttons controle). And some pretty new may even report the actual percentage it´s opened/closed. But I believe most is working just like the in the US.
Damit!
I wonder why the heck it´s even a rollershutter type (or why it requires a percentage value)… I have seen several rollershutters for curtains, windows etc which doesnt work with percentage. They work with pulses, and just exchange the “live” wire to the motor when reversing…
I do have the state machine proberly set up. Infact I believe the Marantech 252.2 opener (motor) I´ve got even work with timing for fully open/fully closed. One have to code when the motor should stop in fully open and fully closed. But thats the inside logic of the Marantec. I have seen rullershutters beeing calibrated exactly the same as well.
I fear that using timing in openhab may result in some latenzy which could become a problem. But it sure would be a fun “little” project to test. At least it would force me into dealing with timers in openhab, which I havnt figured yet
I couldn’t say, but it is consistent with the garage door icons as well. From a purely mechanical perspective, the only difference between a rollershutter and a typical garage door is size. So I can see why one would want to use that representation. But I agree, it does somewhat ignore how these openers actually work.
If you just translate any command you send to GA as a button press, you can end up with situations like:
Garage door is opening → “Close the garage door” → Garage door stops
Garage door is open → “Open the garage door” → Garage door starts to close.
Garage door is stopped → “Stop the garage door” → Garage door starts to move
and so on. To get a consistent behavior you would need to know the state of the garage door and issue the zero to two button presses that is appropriate to get the door headed towards the stated goal.
No, the garage door opener already knows when to stop for fully open/closed. And you have sensors to tell you when it is fully open or closed. That marks your end points where you recalibrate the percentage to 0 or 100 as appropriate. When the door is in motion you need to use the time to estimate the percentage.
Not really, all the timing is being used for is to estimate the current position of the door, or to set the door to a specific percentage open. If it’s off by a few percent does it really matter? Remember, as soon as a sensor says the door is fully open/closed you will short circuit the calculation and reset it as appropriate and cancel the timer.
See Design Pattern: Looping Timers as this will be the what you need to do. For JSR223 I’ve written a countdown timer which might be applicable to this with some minor modifications.
Ohh, I know Thats how I run it atm… (I ask GA to “start the garagedoor” whenever I want to either open or close it… It´s very ackward. And GA have no idea if the garagedoor is opening or closing, or even running). Thats why the logic will have to know, what was the last direction it ran as well.
However, I truely dont believe GA take this into a matter at all, (I´m not sure as I cant test, yet). If Garagedoor is already open, and you ask GA to open the garagedoor, then I assume GA will try to open the door again. (Stupid GA). At least thats what GA do with lights.
It´s what beeing coded when the garagedoor is set up for the first time, (I havn´t tried myself, cause our garagedoor was installed by a company. But I saw the Marantec instruction at youtube. It´s like calibrating the stop ends for a blind/rollershutter).
The two sensors I´ve got, doesnt integrate with the garagedoor opener… Its two simple wireless sensors, one located at top and one at the bottom I´ve installed myself for openhab purpose only (monitoring fully open/closed).
But you´re right, these sensors will be the triggering items for the timer to start. And the time from fully closed to fully open has to be calculated and turned into numbers. Thats the hard part And I probably need to measure the time from fully open to fully closed as well, as it may not be the same.
Thats a part I cant figure yet (wether it´s important). Since the sensors dont integrate directly with the controle of the garagedoor opener, it could result in the door beeing fully closed, but openhab/item shows xx% wrong, unless I reset/set the percentages as well, when the door reach the sensor. Hmm, That would probably be the best thing to do anyway.
I´ll take a look. I could probably use some of it to get a better picture…
If this project will ever succeed, next step is a Dimmer controlled from a single push button… I believe it´s almost the same, except the time is alot faster
I never said it did. You would be writing this code outside the garage door opener. All the garage door opener ever sees is “someone pushed the button”. Figuring out the direction, last direction it was moving, and calculating the percentage is all on you to code in openHAB. If you say “open the garage” the button gets “pushed” and the opener retracts the door until it reaches the stop point. You need the sensor so that openHAB knows when the door is opened. The garage door opener already knows.
For that matter, the garage door opener has no idea what percentage the door is open or not. So the re calibration is also purely something you do in openHAB. The opener doesn’t know and doesn’t care.
Correct, but luckily we just need a percent so the calculation is pretty easy:
time door has been in motion / time to fully open/close = percentage
Start at one end, let’s say closed, at 0.0 seconds. When it opens, add to “time door has been in motion” until the door stops or reaches fully open. If you stop part way or are fully opened, subtract from the “time door has been in motion” to indicate the door is moving in the other direction.
That’s what “recalibrate the percentage to 0 or 100 as appropriate”.
This is simpler as I Dimmer supports INCREASE/DECREASE which moves the brightness a set amount. So you just need to repeatedly sendCommand(INCREASE) while the button is pressed I think. You don’t have to guess and calculate the percentage.
Ahh okay. I was unsure if you had misunderstood my sensors.
And we´r agree, th logic will be placed inside openhab… Thats the goal
As usual, you make it sounds so easy But I´ll probably figure this better, when I have measured the time.
You´re right, I dont have to guess and calculate percentage, as dimming from a button is most often done while looking at the actual light. But logic would need to know the last direction as well, when this is suppose to work from a single push button
And to distinguish between turning dimmer on/off or increase/decrease brigthness, the use of short/long press as well.
(I actually wonder how come noone has done this script/rule yet. Maybe its not so typical to controle a dimmer from a single push button in other places).
Anyway - I´m possitive, wether doing this garagedoor/rollershutter “software simulating” rule or “one push button dimmer” rule first, I can probably make use of some of the code, or at least the experience.
Which you already know how to do from the garage door state machine code.
Because ultimately you will be dissatisfied with the results. OH isn’t a real time system and keeping up with anything in the sub second range is not reliable. For something like this it works so much better to implement it at the device instead.
I know there may be some issues doing this.
In a specific situation, like having one system controlling another system, it can be the only way to make it work.
Ie, if I want to make use of a IHC push button to control/dimming my Philips Hue lights. There is no way to do this, other than to create a rule in openhab, and live with the result, which hopefully will be better than nothing. Adding a Hue dimmer switch is out of the question. First of all, it´s ugly as hell. Second it wont fit anywhere in our house.
Which may mean it cannot be made to work. Especially with Rules DSL and often depending on the nature of the technology.
Based on what I’ve seen on this forum, no, the result will not be better than nothing. The result will be pretty close to unusable. The latency is too large and inconsistent. You’ll never be able to achieve the desired brightness with that button.
You may be right Rich… Others have said the same… I just dont understand, that a very small computer (IHC controller, running somkind of Linux) can do it, but an Rpi cant…
It’s not the computer, its the network communication. You have:
IHC sending a wireless message on 433 MHz (I’m guessing)
A receiver on the OH machine receives and decodes the message
The message get’s passed to the OH binding
There is an Item event
Your Rule triggers
Your Rule sends a command to the Hue Item
The binding get’s the command
The binding sends the command to the Zigbee Coordinator or Hue Hub
The coordinator or Hub transmits the message to the bulb
The bulb receives and decodes the message and performs the action.
Every one of those steps adds latency, a lot of latency in some cases. If you are using the Hue Hub the latency is even more because you have a WiFi hop between OH and the Hub instead of a local serial connection to the coordinator.
When you try to send messages along that path too fast, you can end up with the messages piling up on top of each other which can result in messages being dropped.
But when you have a local control with a microcontroller, even something as low power as an ESP8266, there is no networking latency. The microcontroller directly talks to the bulb. Or if you are using a Hue dimmer, you cut out almost all of those networking hops an the dimmer either directly talks to the bulb or it has to hop a bit through the Zigbee mesh. Almost all of that latency is gone.
Thats how I run it atm… (I ask GA to “start the garagedoor” whenever I want to either open or close it… It´s very ackward. And GA have no idea if the garagedoor is opening or closing, or even running). Thats why the logic will have to know, what was the last direction it ran as well.
And I probably need to measure the time from fully open to fully closed as well, as it may not be the same.