larryllix

LOL. I have been writing software since 1973 and python3 is a huge learning curve for me. The documentations is terrible and everybody offers guesses. LOL Try the parenthesis around each logical comparison first. I don't think my python3 behaves correctly and I have never spent the time to investigate but I have had lots of problems with compound logical comparisons not function the way I thought they should.

My son bought a massive house a few years old with illegal wiring in it. Trouble is there is nothing you can do about it. By the time you figure out the washing machine has a defective GFCI receptacle making it erratic, located behind a built in fridge in the kitchen, it's years down the road and no court is going to sit and listen to things, when you had an idiot rated home inspector go through it to your satisfaction, before laying down your Bitcoins. Half the walls would have to be ripped apart to fix all the white hot wires used in the upstairs wiring. Every month or so when I visit I find another gottcha' that should be cause for gun ownership in Canada. What can be done? Sell it to some other unsuspecting non-tech sucker, that may never know some receptacles have no power. Not nice, but either was the purchase. Buyer beware. In my next life I wouldn't touch a house with work that looks like a self-styled contractor. Who knows what evil lurks in the darkness of the walls?

As per KeviNH, I do a similar thing. While writing code, I do a print('XXXX routine:', param1, param2) on the first line of every function. If there is problems you can read the list/log and determine what got sent where. Once things are working reliably then comment out all the first line print(..... lines and leave them there for later debugging, if ever needed. This is not involving ISY or the pi, but rather, only your program code.

I am not familiar with python2 but some loose observations on the layout - no return on functions to separate main from function? I know there are lot of pythonisms that I avoid. - I found with my python3 multiple element boolean logic needed parenthesis to get order of operations correct. I was never sure if this was a bug in my compiler or I needed to study this more. It should work without them but I have had lots of trouble with them working bare.. if (a == b ) or (c != d):

As an afterthought I have had freak-out guests ask me if the MSs in the bedrooms were webcams.

I do this to with a separate program that dims all the SwitchLinc LEDs as well as the bedroom lamp and bathroom levels for "the pee run in the middle of the night". 100W equiv. bulbs ae pretty nasty in the middle of the night. If your proram adjusts the proper level for manual operation it looks fine. You may want a Wait between the scene level sets because they capture the Insteon protocol for a fair chunk of time that coud block other HA Tx items for a second or two. The scene levels are all kept in the Insteon devices.

I don't know how the ioLinc can tell the difference between ISY and any other Insteon module. This makes me wonder if UDI has created some workround to a protocol problem that causes different responses to be encountered.

I sold a house years ago full of X10. The market wasn't good then and it took a few years. I wanted to keep the X10 modules so after the offer was signed I took the wall switches out and repaced them with the smal rocket type mechanicals that matched the rest of the house. I worriedabout this for the next few months until the day of the closing inspection. When the people came to inspect, the first the women did was to go immediately to the switch in the front hallway and demand, "What happened to to the weird switch that was in here?" I told her some BS about being part of the security system that wasn't included, and she retorted, "Good! We thought we were going to have to get an electrician to replace them all." There has been many discussions about this over the years and my take is, it depends on the area and price of the house. Most people do not want HA in their home, or they would already have it. I feel it is like a badly done by the owner basement. I am just going to have to rip it out before I can do it properly. I have three very techie sons and none of them like HA. Every time they come to stay I find all three bedrooms with disconnected lamp modules (no WAF?), as the stupid things kept going off when they got in bed, or the light might have woke the baby up, despite only coming on at 11% after 8 PM. Typically home buyers don't like weird. If that is showing, then what have you done behind the walls? The trouble is, you will get no feedback on it, and the buyer just never comes back. Here the Realestate agents make sure you never meet the buyers. I found RealEstate agents will not even advertise the feature either, and that would be a good starter to attract a certain type that would even appreciate it. But times are a changin' too. I still have all the X10 modules in a junk box in my storage room.

This is awesome work Wingsy! IMHO you should mention upfront that this is a result of your testing (maybe a brief description of technique) so people don't think you just translated the manual. My confusion needing clarification: Momentary A "ISY Off command does not ever trigger the IOLinc but a linked controller can trigger with Off command". I believe ISY would be a linked controller or the same as a linked module. No? I know you are fairly adept so I am confused about that one.

Yes. A simple logic grid would be worth a thousand words. SH never seemed too good at logic, or conveying it to users. I think a new thread with the appropriate title would be good.

Many have selected this option and only ISY programs turn the lights off again. Using If control/switched On only detects On signals and no second program would be needed to isolate the Off from causing anything to run.

The manual I have is not very good with descriptions of how the sensor to Insteon logic works. The only idea I can see is, use the IOLinc alone, in the Momentary A mode (monostable mode) with a 1-2 minute timer settiing, and hope that ISY could possibly retrigger the monostable timer with a program hitting on the timer every say 30 seconds until the desired time is reached. Otherwise, the monostable timer may be enough without an ISY off timer program. IIRC it also has a mode that is supposed to ignore any Off signals from Insteon but no mention of what the sensor input Off will do to it. Did you see my thoughts on K1 snubbing above?

I haven't ever used an IOLInc with output following the input but can you not override the Off cycle with the ISY program? How long does the sensor pulse last? Maybe a small RC/diode network on the input? Possible a feedback loop to make it latch? I would have to study the follow me options in the IOLinc to see what they are capable of.

Can you not just eliminate the timer relay all togther. If the IOLinc can handle the LED current directly, and the IOLinc is set for it's contacts to follow the input, then you should have no ISY Insteon signal delay. This is provided you can adapt the sensor to the IOLinc input.

Based on the clues given that turning the IOLinc On and off can give All-On problems and that yhe IOLinc contacts are break before make, I would say your snubber diode across K1 is not performing well enough. It seems the counterEMF spike is driving the IOLInc around the bend causing it to issue these erroneous signals as it reboots/crashes internally. I would be scoping this, or at least trying to improve that part of the circuit with a series blocking diode, replacing the snubber diode, or adding a parallel despiking disc cap accross K1. The IOLInc contacts are only rated at 30v and the relay is running at 12vdc.

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.