I have a winch I’d like to automate using openHAB. It has a two way push button to control the winch going up and down. When you don’t press it, the winch doesn’t turn. When you pushing the button upwards, the winch winds one way. When pushing downwards, it winds the other way.
Looking at an electrical diagram, I saw the following:
It operates at standard current: AC 230V.
Both signals are switched. So there are 2 signals in and 4 out.
When not pushing the button, none of the out signals are connected. When pushing up, 2 ins are connected to two outs and when pushing down, the ins are connected to the two other outs.
The construction of the button prevents that the ins can be connected simultaneously to the out signals for the opposite winding senses.
Does anybody know if an openHab automatable thing exists that I can use to replace this switch?
Safety hat on: is it sensible to activate this when there is no-one supervising it? (The design that requires you to stand there holding the button is a safety feature which you should think carefully about before defeating)
Apart from that, it’s the sort of thing you might do with a Shelly or other device suitable for garage openers etc.
rossko, safety first indeed. i’m not planning on operating my stuff fully automatic, but under supervision via an ip camera and using a button on the same openHAB mobile app. (Also an openHAB integration.)
Depending on the power required, but a Sonoff dual, or sonoff4ch fit the bill.
You’ll have to make sure that the relays are on mutually exclusive mode to avoid sending power on both circuits at the same time.
The Tasmota firmware can deal with that easily.
MDAR
(Stuart Hanlon, UK importer of Velbus hardware)
5
Just in case anyone with a Velbus network is interested, this would do the job
I’m with the safety side here. Panic, let go the button and it stops. With OH in the middle you’ve put a layer I don’t fully trust.
Having said that, if it’s opening a chicken coup then fine
A sonoff dual won’t work as it’s single pole single throw. You can find dual dpdt esp8266 (and flash with espurina) on banggood. They will handle 10A and cost next to nothing.
As there is no mechanical interlock between the relays please fuse it appropriately incase the software “interlock” fails. Better a blown fuse than fire.
What is the lag between the actual events and when you see it on your OH mobile app? In my experience that can be up to a second or more. Watching a video of what happened a second ago is not what I would call positive control.
The reason why the winch requires you to hold the button down is to force positive control. If you are not there and you are not pressing the button, no movement: fail safe.
In your proposed system, you are seeing the winch moving with a lag, and if something goes wrong (e.g. network connectivity is lost) the winch will just keep on going potentially causing injury or damage (perhaps to itself). There is no fail safe.
I’d strongly recommend against this automation.
That would be a bit safer, but I still wouldn’t recommend this automation. Stuff like a winch really should have positive control. A timer wouldn’t completely solve that.
You should be able to use any decent roller shutter module that works against shutter motors to have a switchoff mechanism (not sure about the proper English term here).
That is, you usually set 0% and 100 % with some kind of screw and the motor switches off if the shutter reaches that position. Then on calibration, the actuator notices the power drop and concludes this be your end position (0% or 100%). I think if you have a manual up/down switch to stop when you release the button then you should be able to imitate a blinds motor behavior and make use of the calibration feature.
There’s KNX and ZWave roller shutters such as the Fibaro FGRM-223 available, and I think there’s even a Shelly (WiFi) product. Not sure about the latter, but Fibaros are successfully used by many OH users.
Strictly, the original pushbutton/switch are double pole. That’s a good idea to electrically isolate the winch and cabling when no buttons are pushed.
But most likely it is that way just because the the switch design used can also be used for a reversing DC winch motor, or even a 3-phase.
If you were confident that the gear was reasonably protected from water and physical damage (and it should in any case have a circuit breaker), you could permanently wire the neutral side and use single pole switching.
Hi Rich,
Thanks for your replies. I hear you. My thoughts on your advise:
A delay of a second between real live and appearance on the mobile seems acceptable to me. But maybe it would be a good idea to calculate and display this delay and put a safety in the system that the delay ought not to be higher then (maybe) 1,5 seconds.
Shouldn’t it be possible to implement the positive control logic over an OH / IP communication? I’m thinking of a button on the OH interface; if it’s pressed, it constantly sends messages to the (mqtt) switch/relay thing. The thing would only connect as long as a steady stream of messages arrives. It would disconnect and stop the winch in any other case.
The winch currently already has one mechanical automatic stop feature: If the up-winding reaches the end, this is the point where it has successfully lifted the structure it needs to lift, then a mechanical switch already interrupts the winch winding up. It can still wind down however.
The openHAB end is certainly do-able, run the winch for 1.5 secs and restart the timer when a new message arrives.
I don’t know how you’d do the UI end, depends on UI.
It does remind of how camera PTZ controls often work - if you were using some CCTV UI you might be able to adapt existing PTZ control.
Hi Rossko57,
I just timed the procedure from bottom position till up position, where the winch automatically stops via the mechanical off switch. It was around 9 seconds.
My idea about a steady stream of messages, to create a button function, I was thinking about 5 or 10 messages per second. Not one every 1,5 second…
But your remark on the UI seems important: The delays between OH and the switch would normally always be low, as the two devices are both part of my lan. But the UI and the OH server can be in different countries. So between these two devices is where the delay would typically appear. So the challenge is actually to have the ‘timer’ function starting from within the UI instead of from within the OH server.
Sure. The idea is that the next message arrives before the timer expires, and restarts the timing. You’d set the time to the longest you can tolerate laggy interwebs or chickens being hoisted or whatever the risk is.
I don’t follow. The bit I was talking about was at OH, which we’re expecting to get message events “go up” from time to time. OH will need to extend each event into a finite motor run time, that we hope will run into the next event for smooth operation. If/when the events stop coming, we stop the motor.
The UI just needs to stream messages when touched. OH might ignore those if it is already at the end of travel. OH is in charge.
Completely independently of that, OH can keep track of how long the motor has run in this or that direction for a rough position indicator %. This is where your 9 secs come in.
When that indicates fully up or down (plus a bit of overrun) we stop the motor anyway, say 105%.and -5%. Every time the mechanism gets fully open (plus a bit) and your interlock switch has really stopped it, we can re-zero the position indicator.
It would seem to me that having OH to be the system that actively stops the motor does not satisfy the risk issue raised by Rich. The thing/switch/relay that is physically making the electrical connection for the winch should be a device that automatically disconnects power if it doesn’t get the continuous stream of messages telling it to connect…
I agree with the idea that OH expects a steady stream of “go up” messages. But I think that a steady steam is not sufficient. My idea was that the delay of each message between sending (from UI) and arrival (at OH) should also be timed. And if it is to high already at the start then it might also need to be discarded. Messages from me (UI) till winch (switch thing) should be within a time window just as the video should be within a time window, in order for the system to be sufficiently fast. Actually this is a real time requirement.
Indeed, this seems like another security feature to prevent the winch running uncontrolled.
I think that’s over the top really. The risk being mitigated there is of openHAB or LAN etc. dropping dead in the middle of an operation, which is quite low. I’m assuming this is not a life critical machine, like a passenger elevator or a ten tonne crane.
Coding errors are no more likely one way or the other, but I’d vote for simple.
Having said that, of course you would exploit any maximum run time that could be set in the chosen relay gubbins, just as you should exploit up/down interlocking. Better still would be adding the other limit switch.
