larryllix

Remember... Insteon Scenes were intended to be presets for levels and ramp speeds that can be used later. When you manipulate scene levels you are writing preset parameters to a switch or other remote Insteon device, and changing the Eprom settings inside the device each time you change it. You could wear out the Eprom in the device and it also takes time so if you manipulate Insteon Scenes in response to some program trigger like and MS, expect the response to take several seconds and your Insteon comm system to bog down while this is happening. Most devices take up to several hundred scene presets.

It bothers me that your circuit idea isn't working and I can't formulate a possible reason why. It should work fine. I have a few ioLincs and the one for the garage door has flakey comms occasionally. They are not dual band. Sent from my SM-G930W8 using Tapatalk

These things can be frustrating, for sure. It may not be related to what you are doing and about a defective IOLinc causing erroneous signals. I don't believe the signal is an ALL-ON Insteon signal but rather a Insteon Scene signal that may contain most devices. I had an OnOff Module that was sending out a particular scene on occasionally instead of an ACK when I turn it on. For a year or more I noticed a recognisable pattern of lights on when I would come home and always thought it was my bad programming doing it for my "come-home" algorithm. Most lights were dimmed to various levels which match one of my Scenes I had set up. When I looked at the error logs, I mostly found my humidifier had just turned on and it logged an error instead of an ACK back. I simply power cycled the plug-in OnOff Module and it went away after about a year of frustration .Now it has been about another year and it has never happened again. These Insteon devices are just computer programs running on a microcontroller, and a run-away program can send anything out.IMHO Insteon scenes can be especially dangerous as they are too easily sent by bad devices and without fully understanding the process, have very little checking involved. With all that said. Have you tried replacing the IOLinc? Factory Resetting it? Was it factory reset from new before connecting to ISY?

Here is what I reformatted to....Stu may be interested also.

OK. I have resketched your combination diagram to show the scheme and better understand what you are doing. You have a slight shortage of contacts on K1 relay and require diodes to share contacts on the IOLinc and K1 relay.:) AFAICT this should work just fine as your K1 relay sees the sensor and seals itself in until the IOLinc transfers the seal-in from it's own (K1) contact to the IOLinc N.O. contact. I see no problems with this circuit except some concerns is the contact rating of the IOLinc sufficient to carry the current of the LED lighting? The Relay K1 makes the initial surge portion but the IOLinc has to carry the load current and break it. Breaking it shouldn't be a problem on a bunch of LEDs without counterEMF if they are sufficient to carry it while running. You have your IOLinc divided into two completely separate functions that don't interact. (I don't know the setting jargon) ISY sensing a signal from an IOLinc and immediately sending a command back to the same device can cause the ALL-ON phenomenon (allegedly) .Since the K1 relay contact seals itself in, the ISY program to transfer the seal-in to the other IOLinc contact (N.C. to N.O.) should not need to rush and I would advise you to install a Wait 2 seconds into the program that responds to the IOLinc and then times the circuit off later. Something like this If ....control IOLinc is switched On Then ....Wait 2 seconds .... set IOLinc to On ....Wait 2 minutes ....set IOLinc to Off Else ....(empty) Try it and see what you think.

This sounds like you are following the sensor signal sent from the ioLink with an immediate relay signal to keep the LEDs on. This is known source of all-on problems. I will have to redraw the circuit as a proper schematic to see your logic flow.

I spoke too soon. Two of three GH minis can control the HA but the third unit shows all the devices but always reports it cannot control the HA devices. I have power cycled it and browsed it's setup to find differences. The only difference I can find is it only displays two accounts, with the "Anonymous User" account missing that the working two GH minis display. I have completely deleted all accounts, along with the app and cleared my phone's cache, starting from scratch three times without making any difference. ISY Portal still reports connection refused from GH end. I have changed my Google password, resetting all my email apps and a few other account accessing apps. No luck here, so far.

OK. I think I have found the problem....partially. I use two accounts. One account for HA and one account as a common calendar for the wife and myself. (This is a PITA with google calendars) The GH app lists boths accounts and both accounts have complete duplicate setups. Very weird and I don;t know why they would do that. Somehow my UDI account link got installed into both email accounts and must have confused GH synchonisations. I unlinked UDI from one email account and the UDI devices were all still present under the other email account. The vocals now function properly but I still cannot download the associations to GH yet.

I just tried that but despite deleting and uninstalling the app, finding the memory cache and storage and deleting it then reinstalling, the GH app already knew of both accounts and all the UDI devices. Unlinked and relinked with no success. I am going to do it again and see if a memory clean and mobile reboot helps clean things out. Too many things ask for passwords for the same account without clarifying account for what and all using the same email address. Portal has about three different accounts and none are specified what account it refers to.

OK. I have unlinked the account, rebooted the GH app and linked to my ISY portal account again. All devices downloaded and showed up in the app again (63 devices). The same results occurred again when I open the ISY portal and attempted to download the devices to GH. I get the same "No Permission" error. When addressing a GH mini vocally, I get the same response "I'm sorry. There was an error and I am unable to control your home device" This makes no sense that GH can connect to the postal and extract all the devices successfully but not communicate for HA control purposes. No changes were made and only the router in between was down for about 5 hours.

Thanks Sure. What is that? I don't see any linking for the ISY portal to GH. I only see an account link from the GH app and that has been done already as mentioned.

I have both systems and they are not very compatible with each other. GH does not have the freedom of phraseology and makes assumptions. Alexa asks again or uses the phoney phrase "There are several devices with that name". I can control lights, devices, programs also, but the phraseology is very restrictive to avoid incorrect triggers. eg. When GH first arrived, I had to change the name of a my Gathering Room lights. All lights were originally in that room and I had one program called "All Lights". Hey Google! Turn on All lights...lit up the whole yard,porch, deck, and every bedroom, basement etc. Nobody ever called those devices "All". GH assumed it. Red Lights and Red Bedroom Lights mean the same thing and Lights (plural) means all of them. Another assumption that causes me problems. GH is very limited to the number of devices due to short naming problems. This may be ISY portal. I am not sure who/what is doing it.

I made the mistake of assigning rooms to some devices. Now when I use the room name with a device (existing with Alexa) all the devices in the room activate. So far GH is junk for HA due to it's assumptions it makes. They call it AI.

There was a copy over from Alexa devices to the GH pages but I found it didn't work properly in many cases. I have also found GH spokens only understand two words, the first and last. So if you say Hey Google! Turn on red bedroom lights....GH will turn on everything in the house with those two words Red, and Lights. As much as I like the smoothness of the GH over the Alexa responses it's HA is just substandard (and dangerous) so far. I am not sure if this is due to the ISYPortal implementation or GH itself. I am starting to avoid using my GH minis due to not being reliable for HA, so far. GH makes assumptions of what I heard and turns on banks of units not wanted. Alexa does not do this.

I am not sure this is related but DST time change caused my router monitoring power cycle program to activate at 3:00 AM last night (not my query all set for 4:00 am) and my router ended up shut off for the night. I think I found an ISY program race condition possible and believe I fixed that ISY program. After the router powerup in the morning, the Google Home minis would not reconnect to the WiFi so I power cycled them to fix. Now my GH minis have Internet access responses but will not operate my HA via the ISY portal. Alexa devices work fine, as per normal with Internet smarts and HA via ISY portal. From the GH app I deleted the UDI account and reinstalled it. All ISY portal elements re-appeared in the app again. From the ISY portal webpage I checked the ISY element/device list and they all seem normal. When I re-download spokens to GH, I always receive this error. "Error sending your spokens. Google home API returned: PERMISSION_DENIED The caller does not have permission" ....and I cannot control an HA items from my GH minis. Help please?

I would. I consider v5 stable and as finished as any high-tech product I have ever bought.

Your repeat construct is used incorrectly. Move the Repeat up two lines and notice what happens to the format of your program. I notice you using a scene to operate this light. Does the scene contain more devices that just this one? If you are using V5 you can save the light level into a variable and then restore it from that variable when you are done.

Contact UDI. They have some deals for people doing this and can transfer licenses from one unit to another. Sent from my SM-G930W8 using Tapatalk

This makes me wonder if a ct around one conductor of the load feeding a few wraps of wire around a CAO Tag would detect the magnetic field? Even a split extension cord with conductors wound around it in opposite directions to make the fields additive instead of subtractive? That also keeps the conductors the same length and tidy. If these these Tags can detect earth magnetic poles........ Hmmmm.... some experimentation is in order there. Wife misses her dryer done doorbell and notifications a lot. Sent from my SM-G930W8 using Tapatalk

Yeah. The system variables are not available directly in logic equations. They have to be assumed into a variable in another program with a sampling loop. Then they can be used for program triggers. Sent from my SM-G930W8 using Tapatalk It should be noted that ISY only has a cheaper hardware based clock and may not keep good time without an occasional online sync.

First. With Insteon you don't query devices unless you have system defect. If temp > 80 Then set xxx on Else set xxx off Sent from my SM-G930W8 using Tapatalk

Nicely done Fred! I find it easier to just write my own a lot of the time as the docs these days on hobby level stuff is so bad I have no idea where to even type in the lines given. [emoji20] Confused by your overlays. You aren't running admin console on the RPi are you? Sent from my SGH-I257M using Tapatalk

Just try Hey Google! Turn On the lock! Hey Google! Turn off the lock! Point it at a program, scene, or device of your choice with a vocal definition of "Lock" in the ISY portal, in the vocal to ISY element assingment table

If (disabled) .....status is on Then ....turn it off Else ....turn it on

Yes Thanks! 20 Watts seems very low for a sump pump and the time delay is quite short for a well working (and set) synchroLinc. Do you know how many Watt the pump draws when running? You can get that by turning off the time delay (0s) and increasing the Threshold to where it just barely turns on. Right now you have your On being sent at 20 watts and Off at 15 Watts wit only 1.34 seconds delay to send the On. This may just make it erratic as these things are made for loads up to 1800 Watts. That is working at the very bottom and maybe erratic end of the metering. Metering is not real good running at 0.3% of full scale hysteresis. That may be below it's resolution making the 5 Watts less than one count of change in the metering result. My sump pump is 1/4 HP and cycles on for shots of about 10-15 seconds each cycle. Just enough to clear the sump pit and then rests again for a few minutes or a few hours. My thoughts are you have a typical sump pump drawing a few hundred watts meaning your threshold may work better at 100-200 watts and then you could set your hysteresis somewhere around 100-150 Watts, No matter what the load of the pump I would set the time delay to 4-6 seconds if you think it is rattling the contact on/off.