No. You are transmitting messages over a network. The network could go down. If that happens you have lost positive control over the winch.
You can’t guarantee timely delivery of the messages due to network latency and processing by the broker and such.
I’m not convinced that any of these proposals is a sufficient replacement for this safety feature. The risk doesn’t come so much from the winch but what the winch is carrying. Typically a device with such a safety feature is designed to lift heavy things. Moving heavy things can kill. I would never find it acceptable to rely upon WiFi to maintain control over something life threatening. There is no solution that will involve openHAB that I would find acceptable.
Which is not something that OH and it’s UIs will support. you would have to write a custom UI at which point OH really isn’t doing anything for you so you may as well do this wholly within a custom set of software.
OH does not support any sort of real time processing requirements.
Even a low risk where the impact is injury or loss of life is too high. If this winch is lifting Styrofoam balls, is not strong enough to lift a person, or is operated in a place where people an animals are prevented from being near the winch then maybe I could be convinced it’s reasonably safe. But if this thing is operating around people or animals, is powerful enough to cause damage (it takes less than a second to break someone’s fingers if they are messing with the chain and the winch starts moving), or is lifting heavy things that could cause damage if they run into someone or are dropped on someone even the risk of a loss of LAN is something that needs to be dealt with.
I’ve known people who have lost fingers to winches. These are dangerous machines that require respect and special attention to safety.
Check out my Hackster project it uses 4 different controlled relays using a particle … Cheap to build https://www.hackster.io/Jade7272/hacking-an-irobot-to-act-as-rc-with-adacore-particle-28bf69
All this safety talk is tiring I am sure you know what your doing … Most of what you need is programable in c++ where you can put timers and safety switch inputs directly which are better use MQTT as inputs and outputs for winch control which is easy to do in openhanded
Your post is pretty off-topic and, worse even, dangerously misleading.
Please correct or retract it or I have to.
Safety talk (sometimes) IS important.
That’s what this whole thread is about: power rating of relays (actuator-builtin or standalone) and safety mechanisms to apply.
You probably never had a fire caused by fried electronics or accident due to misfunctional control programming … but others do.
And a winch has a big potential to do harm. A toy robot like the one you promote does not.
Actually the first question is I need a thing switch to control a winch remotely… I’m not retracting shit… small control relays always control larger contractors to control heavier load motors … Safety is the installers responsability not a bunch of keyboard warriors throwing in their 2 cent opinions
WilamG if you still need a control diagram I’ll do one up for you … Attach a picture of your winch
My question was not precise. I am trying to design a solution that meets some of the safety concerns you raise. Such a remote control system would require to halt (disconnect) immediately from the moment that the mqtt messages are not coming in a steady stream. So if the network is lost, the winch stops automatically. This ought not be a function of OH telling the relay to disconnect. It would be the Sonoff style switch to automatically disconnect.
It would also be required that an mqtt message, part of the message stream, is checked for delay (or round-trip delay is measured). If the delay is higher then a cap, then the messages should be ignored, to ensure that the delay between remote operator and relay control is limited. If this not the case => relay breaks.
And the video delay should also be part of the system: If not within a bound then relay breeaks.
This doesn’t need to be a problem if the relay stops the winch in case of message delays.
Same idea: My idea is if control is lost, then the winch must automatically stop. This should be in the logic of the Sonoff style relay. Not OH. So indeed, OH should not be part of the solution. The Mosquitto mqtt broker would, but not the OH server. This would also lead to the requirement that the virtual button in the UI should be the originator of the mqtt messages… Which is something the OH mobile UI is not designed to do, as you wrote.
It does look like the system I am thinking of is moving away from an openHAB project…
NodeRed would be a good solution … It can be installed locally which speeds up response time … It has graphic nodes … And buttons and can communicate with just about anything sending data …Like I said earlier a lot of the safety controls can be implemented in the controller programming including proximity sensors and timers and shut offs …
Jade, I am aware of NodeRed but I haven’t yet studied or used it. Would it allow measuring time between the mobile UI and the sonoff-style relay and build logic upon it? Thanks
What your talking about is predictive analytics … Whole different ball of wax … the devices I use are particles … www.particle.io they have BLE mesh units as well as LTE and WiFi they actually give you some analytics on their dashboards … there are literally 10000s of sketch examples and a rally good support community … They are programmed on line or locally on a Linux … Pretty slick units … Hackster.io could probably help in the predictive analytics part as well …sign up and do a search there . I hope I helped
Much of the chuntering here is because we do not know what you are doing - raising a castle drawbridge, raising a flag, opening a chicken coop, aligning an aerial. Tonnes or grams in motion. Risk of crush, damage, hoisting aloft, fingers in mechanism.
It strikes me that if you feel the need to create an elaborate setup for remote control, the effort might be more usefully put into making it inherently safe by any means of control. Infrared curtain, over- and under-load sensing, contact sensing, chain cover etc. Same as a powered gate or humble roller blind.
Indeed I’m also getting extremely curious what the application is… as it is carefully not mentioned, curiosity takes over…
Could not have said it better. Probably the OP is afraid the flow of ideas will stop, if everyone can guess the risk for themselfes.
Other people, other calculations…
I hold back my ideas because of not knowing more.
I’m getting all kinds of kinky ideas
Ok. ok. ok. I live in a flooding area. I have a steel “valve”, 50cm by about 3m. In normal circumstances, it lies on the ground and I drive over it with my car. With the winch, I can rotate it around the long edge to the vertical position, where it ensures 50cm of extra hight to flooding protection.
The system works but it is still operated by the manual control (the 2 way push button) that is part of the winch. I wish to be alerted on mobile phone, see the flooding in my street through the camera and decide to lift the valve remotely through a “remote push button”.
The camera has 2 functions: 1) Verify that there is flooding going on. 2) Ensure that there are no people in the direct vicinity of the valve I want to bring upwards.
The valve is on my property, but close (2m) to the street. Directly accessible by anybody. Usually people do’t come onto my property. Especially not at moments of heavy rain. But you cannot be sure.
Hoping this satisfies some of your curiosity and I regained some trust. I’m sure you didn’t guess this.
The 2 people cleaning a gagage, that’s my family. I was not at home.
The valve is even on Google street view… Need I say more?
Hmm, close with the drawbridge
I’d add a flashing light to indicate operation, have a sequence that flashes for a few secs before motion begins.
Even laggy CCTV is good enough to see that no-one is standing on it before action. Can you also see if it is clear to lower?
A breakaway / weak link (“mechanical fuse”) in the pull-cable should deal with most catastrophes. Maybe a damper to prevent sudden fall.
Thank you for the explanation. This adds some more value to the problem.
- You only need to raise the flooding protection remotely (If you want it to go down, you or someone else is directly around and can do it manually)
- The time you have to raise the flooding protection is quite long. (You don´t need to raise it in between 10 Seconds)
I am thinking about a pulse-movement. If you give a signal, the winch will only move for 1 Second and will then stop until the next manual signal is received. Would this be sufficient?
That was also part of my ideas. Like automated fences have these flash lights before and while closing.
As Christian already identified. This won’t be required. I will only drop the valve when I’m there. The valve doesn’t leave the vertical position unless I apply some horizontal force to it (put my foot against it).
I don’t see how a weak link would work and how it would add safety to the system…
Rather then a damper, I am considering a second cable attached to the opposite side of the valve, which would automatically roll up when the valve is being raised and which would be unable to roll down. So if the first cable would break, the valve would remain in the last position. It wouldn’t slam back down.