Since the parameters for the constructor are set up to make sure the switch is 'off' as an initial state, it pulses the off output. This is a remnant from me reusing code. I'll take a look at it tomorrow when I have more time to sort through the logic. I'd like to maintain as much flexibility as possible, as opposed to just removing functionality. With a little time, I'll come up with a solution.
UPDATE: @zachhorton - I have added a new optional parameter, initializeOutputs, to the constructor. It is defaulted to 'false' which prevents the outputs from being energized during startup. Setting it to 'true' will restore the original behavior which can be used to always make sure the system starts up in a known state.
Grab the new IS_LatchingRelaySwitch.h and .cpp files from my GitHub. Setting it to 'true' will restore the original behavior which can be used to always make sure the system starts up in a known state.
It strikes me that this is also a problem with devices that use the original EX_TimedRelayPair library: windowshades and valve. In all three cases, having a timed relay with a non-momentary effect could be really undesirable: one's water shuts off, all the shades in the house go down, or an appliance that was on turns off.
Just saw your reply above as I was typing this. I'll try this out! If it works well, it should probably be added to EX_TimedRelayPair as well.
With regard to starting in a known state, IS_Latching RelaySwitch has the advantage of being able to determine the startup state from its input. I don't know how to get around that with valves and shades to determine what state they're in...
Exactly... which is why these devices always go to a known, desired, default state. There is a parameter in the constructor that allows the user to determine what this initial state should be. For a water valve, one would probably want the valve open if it is for whole-house water supply. But for an irrigation sprinkler, closed would most likely be the correct default value.
Trying to keep track of something like window shades without any sort of feedback mechanism is going to be extremely challenging. That is why most users choose to user a Servo Motor for window blinds, as the servo motor has built-in feedback so it always knows its position. Even in the case, when the microcontroller starts up, the blinds are all set to a default rotational angle.
Yes, that makes sense. I guess the best option in both the shades and valve cases is to simply be diligent in choosing the most sensible starting state (I forgot that I can do that individually for each device).
I tested this out for the latching relay and the initialization-without-pulsing part works, but the initial state is invariably reported as "on." Is there a way to read the the state of PIN_INPUT and use that as the initially reported state? Right now it starts reading that pin only after the first ON or OFF action.
I just tested this and it works as expected. The current value of the digital input pin at startup is used to set the status of the 'switch'. Based on my example sketch's settings, having a jumper between D5 and GND results in 'swith1 on' being sent at startup. If I remove that jumper, the board sends 'switch1 off' at startup. The code does behave correctly, sending the correct value during startup.
Since I don't know what your sketch looks like, nor how you've wired the circuit, I have no way of being able to help you troubleshoot further.
Okay, you're right. When I tested again, it is working correctly. I'm not sure what glitched previously. Sorry about that! I consider this a fully implemented solution for latching relays now. Thank you again for your magic!
Is there a way to use a digital water sensor (which closes a contact when it detects water) so that it will act as a water sensor in Hubitat rather than a contact sensor?
EDIT: One way seems to be to just use the current polling sensor (analog water sensor) and invert the logic. Connecting to ground would then send "wet"... is this the best practice?
Do you have a free analog input pin? If so, you should be able to still use it to detect wet or dry states by wiring an external pull up/pull down resistor.
If not, you could easily modify the IS_Contact sensor code to send ‘dry’ and ‘wet’ instead of ‘open’ and ‘closed’. As along as you name the device as “water1”, the Hubitat code would be happy.
Thanks! For the second method, I assume that would be changing the instances of "open" and "closed" in IS_Contact.cpp. I would have to save this as a different library to avoid affecting regular contact sensors, and use this new library instead of IS_Contact. Is that correct? I do have free analog pins, so I may use the first method for the water sensors, but this second method could be very helpful for other devices as well that have binary states that aren't "open" and "closed."
Adding binary input sensors is very simple and I’d be happy to add anything that you believe is missing and would be useful. HubDuino already supports quite a few “Interrupt Sensors”. What other ones are you interested in, aside from water?
Something like "Appliance" would be useful as well, where its states would be "active" and "idle." My specific application involves pumps in a hydronic system. Specialized controllers operate the pumps, but I'd like to monitor when they are running or not. But "active" and "idle" states would be useful for many appliances/motors/devices that have a binary run state. So that and water seem like they would cover the full gamut of my needs. Thanks for being willing to add these!
I think that AccelerationSensor is the best fitting Capability, since it actually uses "active" and "inactive" as its standard states. And of course, the digital water sensor would be WaterSensor.
Just be sure to open each HubDuino Parent Device and click the SAVE button under the User Settings section after you have upgraded the HubDuino Parent Ethernet driver code. I have recently improved the logic to help prevent errors during the nightly 2am Hub Maintenance routine.
Should I be looking for something called "IS_Water" or is/will this be a modification of "PS_Water"? I don't think you've gotten to this yet, but I just want to make sure I'm not missing it.
