I have a feeling you don’t have leak sensor in your Insteonserver.js file. Unless Scott updated, but the bug @cwwilson08 mentioned was submitted earlier on, so I don’t think it will. I’ll PM the updated file to you in a bit.
I never submitted a pull request. Just pointed scott at the line of code. He will not have any of our changes. Including the one for the leak sensor. I suppose I will clone his repo so we can point everyone to an updated file instead until he has time to look.
@cwwilson08 - I just tested it and if I change it to state: level for a command 12, it doesn't honor the FastOn/FastOff request. So I still have that one at 100 and it works as expected.
@SmartHomePrimer - Correct, I do not have leak sensor code.
Ok. I’m updating the hub right now, but I’ll double check that on my end too. I thought it was working, but maybe I’m mistaken. There’s no harm in it going back to the former for Fast ON If needed as Chris pointed out.
Can either of you help me understand, at a high level, how the InsteonServer interacts between the Insteon Hub and the HE? I was under the impression that all commands are proxied through insteonserver, but I've stopped insteonserver.js and client.js and I'm still able to control the lights through the HE dashboard. I've even unplugged the pi, which runs the insteonserver, and HE is still controlling the lights. Is it just used for setting up the initial connection and for discovering devices but then all communication is handled directly from HE to the Insteon Hub? Are some devices managed directly while others pass through insteonserver?
It is for discovery as you, well, discovered
But it’s also listening for changes. So without it, status does not update when a physical change is made at the device, and input sensors won’t work.
We made the decision not to use the insteon server for control. I believe the insteon server was limited in some way? Cant recall exactly.
The insteonserver is just listening to the hub and sending data to he to update your devices.
I think it was smooth dimming didn’t work with the server.
OK, I just found the time to test. It's working for me when the same line for ON is pasted to the Fast ON section. Perhaps you forgot to click Save Preferences? Please note that the preference must be set and the saved on child device creation. I does not default to ON or OFF.
There doesn't appear to be a way to configure both the contact sensor and relay of the I/O Linc. If I configure it as 2 devices in config, it processes the first device and ignores the second device. Thoughts?
Also, I'm using the I/O Linc to control my garage door. I would have thought that the ideal dashboard item for the I/O Linc relay would be a "momentary" item; however, the relay doesn't appear to respond to that. It works as a "Switch" but then the relay only processes the "On" command and ignores the "Off". So I have to send 2 On commands: one to open the door, and another subsequent ON to close it. Thoughts on that as well?
Lol sorry haven't gotten to messing with i/o linc. Please remember this is an unreleased integration.
Will see what we can do to accommodate over the weekend.
Ok, I totally understand. Just wanted to make sure I wasn't doing something incorrectly. Thanks again for all of the assistance.
I should clarify that I have an IOLinc, Chris does not so discrepancies in what it can do are partly a result of my not letting him know what else was needed. It's possible to set the momentary in hardware. I have used it this way with HE. Does that suffice?
I don't have a garage and I've never used the IOLinc for anything other than a leak sensor and water valve setup. I looked at the sensor function some time ago, but things are different with the contact and motion capabilities now in the Insteon-server and with web sockets. I'll help Chris with a second look at that.
I have the I/O Linc set to momentary (with a 2 second duration) w/in the hardware settings. I also have Relay Commands set to "On or Off closes the relay". With this setup, it doesn't really matter which command we send to the relay, it will close the relay for 2 seconds, then open it. That's really the same way a standard wall mount garage door remote would operate.
So if you think about how you would want to interact with that from the dashboard, I basically just need a button. Something that sends either an ON or OFF command (I don't really care which) but that doesn't look like a switch that is either on or off, since that doesn't apply in this context.
Setup a virtual button and rm to link the two?
Yes. This is the simple way to do it. A button wouldn't be compatible with either of the voice assistants or HomeKit.
Oh yeah, that would work. Growing pains of learning a new system, I guess. I've only just learned about the virtual devices so I wasn't even thinking down that route. Thanks!
@peter_aquino Here's a simple rule that will turn your IOLinc off automatically after a specified time (momentary). The hardware momentary setting will work, but it's possible for it get out of sync if the timing for the momentary open/close is not identical to HE. I did find that on occasion it wouldn't respond when I hit ON in HE if they were both set to 0.5 sec.
I tested this rule [see below] for a while and it worked as expected each time. You'll want to disable momentary in the hardware to use it.
@peter_aquino In regard to using the IOLInc sense function as a contact sensor in HE. I will say that after about 3 hours of testing, at this time I do not recommend it. If it's configured in the IOLinc hardware to trigger the relay, fine. But as a contact sensor, It delivered inconsistent results and I wouldn't not personally rely on. A SmartThings contact sensor is just $25 US/ $30 CAD. It has contact, tilt and temp. It's a reliable sensor. Just has a very large gap where it still shows closed. That's my only criticism of it.
Were you even able to get the sensor to update status in HE? I've removed the configuration for the relay and added the contact sensor but HE fails to receive any updates.