larryllix

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.

Looks like it should work What are the On, Off and timer settings you are using inside the synchrolinc?

My synchroLinc has no order of calibration, or calibration settings. It has an On setting, a power hysteresis (I forget the exact nomenclature) setting and a delay timer. Both the power Off hysteresis, and the delay timer are different forms of hysteresis, one being by power in Watts and the other being by time. If you had a device that drew 100 Watts when On and 10 Watts off, you would set typically the On setting about 60 Watts (60%?) and the Off hysteresis setting about 30-40 Watts (20%) making it sense Off at anything below 60 - 40 = 20 Watts. After that appears to work satisfactorily, you would then add a small time delay so multiple triggers would never happen unless the synchrolinc was defective and not functioning correctly. This has been discussed many time in different threads previously. I know they are not available any more, and mine needs new power supply caps, apparently Have these units changed in the last two years?

The synchrolinc already has a hysteresis delay timer built in. An additional wait should not be necessary in an ISY program. You cannot have a program disable itself and then re-enable itself. When a program is disabled, it stops processing lines. The suggested program does not display it's own name. Sent from my SGH-I257M using Tapatalk

See post #3 & #8 Mine has no problem running the admin console either. It is the creation of all the symbols, avatars and icon in java.

It's not so much the download speed, which is somewhat slow also, but only a single background task for ISY while it still performs REST and event triggered tasks, and shared the Ethernet port, maybe not too bad. IMHO it is the slow java package on your computer drawing every box, icon, and avatar first. This is apparent on the later firmware versions as the admin console boot now displays what it is grinding on. My faster machine doesn't take 1/4 of the time but it is still a painful wait. I don't use the admin console remotely as I cannot see any proofs of my efforts and admin console java just goes away frequently as java decides you don't need it for some reason. The quest is on to get UDI to switch over the HTML5 but they have been busy with Zwave which surprised their work load with so many varying (maybe obsolete) devices. You should see my Palm Pilot load it!

What speed and number of cores is your computer you are running the java based admin console on? Mine takes about 5-6 minutes to load on a single core 2.2 GHz CPU. The java rendering icons grinds it to a standstill almost. Try the nonsecure http port access for ISY. You are on a LAN behind your router firewall anyway.

I have LED strips that show a glow at 1%. They used switched PWM and go down linearly until 0%.

Another thing to note is that Control switched only detects human touch sources whereas status detects any source affecting the dimmer. So it depends on what you want to detect as a trigger. One more - just some gottchas for down the road Control Switched On is good for creating retriggerable timers. Once a dimmer is at 100%, there is no detection of Paddle Tap Up any more with Status (level change) detection. With Control Switched ON it can retrigger the Wait timer and start over each time.

Check your links between ISY and devices. Has to be a confused signal. You know what those are like.

My thoughts were if you are doing a slow ramp fingering you got contact bounce looking like a Fast On of Fast Off.

Do you have delayed writing to battery devices option turned on? Have you put your MSes in Linking mode and wrote the updates to them. Mine took almost ten minutes each to dump the ISY cache into them. Every MS motion sensed would cause a massive Insteon data storm for several minutes. After dumping the cache out, and disabling the delayed write option all is running fast again. I had lights responding 20-40 seconds later with direct scene control to the MSes..