larryllix

Inseparable The wiki states. @Michel KohanimThat is incorrect and should read. "...all such statements are executed before the conditions of the program can may be retested" The following wiki paragraphs are nonsense based on a false assumption.

A Wait line in any program releases the capture of it's time slice to the ISY engine so that the ISY engine can process other time slices, including evaluation of programs conditions and trigger events. Wait does not cause conditions to be evaluated. It only allows triggers to be handled. If there is a new trigger in the same program's condition lines in it's If section, the program will stop and start in the section Then or Else depending on the If section's logic outcome. Without a Wait or Repeat line in a program it will execute atomically without any interuption. I/O and other ISY events will not be processed during that time period.

I would say v5.3.3 fixed this. Works much better without tying up ISY CPU time.

Does your UI and software for the ISY match version numbers?

Make sure to disable the "battery device writes" option button (at top) as it may start to creep back in again. OTOH: that concept may have been removed that parameters inside a MS must be updated to change a scene setup and not be a problem at all. This is the way is was previously and it got changed (concept bug?) for some reason during version updates.

@Brian R. I totally concur with this. I had a lot of problems with this "waiting writes" to battery devices to the point of my ISY bogging commands down to almost 2-3 minutes delay at times. V5.3.3 resolved that. I won't say 'all" yet, but after a week, v5.3.3 looks to have fixed it.

The Pro version is not related to the firmware version. Pro is a module that enables more features inside ISY, along with increased program and variables capacity. There a few more features but I cannot remember them all. Sent from my SM-G781W using Tapatalk

Here is the quirk I found. I had created a program to always wait 30 seconds between successive Alexa Routine requests, by setting a State variable = 2. I was using the State variables also as a request flag = 2 to get Alexa to say XXXXXX, while variable = 1 would trigger the Alexa Routine to say XXXXXX, and variable = 0 would reset. My ISY Portal pseudoMS was set for 1 as the active 'On' state and 0 as the pseudoMS as an OFF state. Here is the problem. When I set the variable = 2, ISY portal would send a PseudoMS event of Off to Alexa, even though 0 should have been the only valid Off psuedoMS interpretation.. Now, when ISY programs would see the request and then set the variable = 1, Alexa would refuse to say XXXXXX because it already had an event in less than the 30 second delay requirement. Of course Amazon support staff have been looking into this for the last 6 months, but I am not expecting any response within the next ten years or so. The moral of the story is, if you send anything to Alexa app routines, regardless of which state change, you have to wait another 30 seconds to cause any routine to run.

Well the third generation Dots are mostly unintelligible, with their mutated bass boost on a 1.5 inch woofer, and the 8" Show is starting to invade my space with advertising so this might make it easier to dump Amazon completely. Trouble is, now where do I go? the big advertising spy company, Google? They could get good money for my sexual habits recordings! Sent from my SM-G781W using Tapatalk

So now we discover Amazon devices are extending our LAN via a 900MHz network, giving access of our Internet service to neighbours and strangers passing by? I will be sure to never purchase any of the newer Alexa devices. It seems they have installed this "network extender" in devices and then enabled it without user's awareness of the seriousness. I thought I didn't like the dirty dealings of amazon.ca before? I have already had it out with amazon a few times over false advertising, lying about shipping and other aspects of purchases, including some immoral issues they are involved with. It just keeps getting better with these guys.

Agreed, but Apple peeps seem to expect and allow that "total control end to end", a little more than Android people do. Then there is those that think everything Internet is good for humanity, no matter what or whose privacy they violate. In the end, Amazon has just violated a huge personal security trust. They constantly attempt to grab your WiFi password "for your convenience, connecting future Alexa devices" and now they have installed your WiFi password into another person's equipment. hmmmmm.... maybe my WiFi passwords need to changed every few months also. Where does it stop?

Now it makes much more sense why Amazon crippled the Alexa app for Win 10, such that any Amazon device user must install the app on their mobile device. I was told 50 years ago. Don't trust big government Don't trust big unions Don't trust big companies. Amazon has a bad reputation for "leaking" and distributing personal data, on several occasions. I was never notified of any Amazon Sidewalk anything. This is the first I have ever heard of it. Maybe they mixed it into 10 GB of other spam so nobody would notice??

Condensing @MrBill's concept, you should be able to do this in one program. Trouble is $iMusic may need to be initialised at power up. With the variable iMusic init to to 0, the initialisation should not be required. By default, the iMusic will be set to 0 without any initialisation. This only works for 0. This will detect 0 to 1 only. AnyOtherValue to 1 will not run whatever process. Program Detect 1 to 0 [enabled] If $sMusic = 1 AND $iMusic = 0 <---------- check old value Then do whatever $iMusic = $sMusic <------------ keep last value for change detection Else $iMusic = $sMusic <------------ keep last value for change detection

I don't really care about any FUD. I don't want any company using my WiFi, LAN without me knowing. Let the neighbour realise the over hyped device they bought, doesn't function unless they "steal" bandwidth from somebody else or improve their own WiFi coverage. What amazon is doing is sneaky and immoral. I never saw any notification or singed any release/permission form. Please don't defend or shill the disgusting behaviour from these digital spy giants as they insert the thin end of the wedge into our privacy enclosures.

I found in a bank of three Switchlincs I need to set each backlight at different values to make the brightness all look the same. Therefore there doesn't seem to be any consistent setting for "default".

IIRC, the backlights have no status back function. ISY only know what it last set them to.

I am not on ToU as have Net solar metering and my provider has never had a meter approved to handle the multiple rates but.... as a consequence I turn on everything I can during peak times because that is when the electrical energy is cheapest, being produced by myself and not making losses on the sale and re-purchase of my energy. If I was on ToU, I would not try to duplicate the bill my meter provides as the meter is more accurate than anything I would ever meter and calculate. I worked in a local electrical utility for 34 years as a meter tech and we only ever found one meter that registered high. OTOH that was a mechanical meter and now I hear the CPU based meters can do anything at random now. If I was on ToU I would build programs in ISY to raise my A/C temps during peak rate times and possibly higher an hour before the peak and shoulder rates dropped back so the discomfort would be low and the lower rate would bring the temperature back into comfort line, immediately after implementation. Possibly the reverse could be done by dropped the temperature an hour before the higher rate became effective. This is quite easy using ecobee thermostats along with ISY Polyglot ecobee NS. In the ecobee stats you can define custom "climates" and just turn one on when needed, with the fail back over to the schedule next "climate" schedule change. That works very well. You don't have to play with temperatures or even know what they are inside ISY. Another thought would be to use your unused basement as a cold storage. Run the A/C more when rates are cheaper, and then run the circulating fan more, with higher setpoints, when the rates are higher, bringing the cooler air up from the depths. The ecobees stats can do that, almost by themselves. I have tried many methods using ISY programming, weather effects upon the house, and it got very complicated and not only needed many self checks written in, used 1-200 programs to accomplish, it failed quite often. The simpler things work much better. Leave the complex things to the devices that are designed to do them without fail. The overall control also has to be minor for me, as I am sensitive to heat and cold changes, and my comfort is more important than saving $25-$50 per year. My ISY control over my HVAC is quite minor. It is more about keeping the zones balanced for me.

ISY v5.3.3 has cleaned up most, if not all, of the battery writes option problems now. Sent from my SM-G781W using Tapatalk

Many of my later DMM used a 1mA constant current as a resistance test current. Then the resistance (in Kohms) you read on the meter was also the voltage drop across the diode. Germanium diodes would read 0.3v+ and silicone diodes always read 0.6v+. It becomes a signature that I would look for when doing an forward and reverse voltage drop on a diode. I never thought of it as ohms as the reading would vary, based on the meter current supplied.

The worst lines will have <unknown device> type comments in them and you will have to redo the line from scratch. Many will have comments and the line can just be clicked on, check the parameters and then click "update" and the line will be rewritten exactly the same but with the hidden links reloaded. Always click save for the programs, when open each session. YMMV

One more thing. Access your router DHCP Reservation table and assign your ISY a fixed IP address. Then your ISY should always be at that IP address for other software, like polyglot and mobile apps, after a reboot or power cycle next time.

I found sometimes that would work but you can never trust it. Check each program involving the devices in question, select each line (so it shows up at the bottom) and click update (to refresh the links behind the scenes) , then save the program. That will ensure that each line is linked to the proper device(s)

Access your router, (likely at 10.0.0.1 on your browser) change the IP address range back to 192.168.0.1 to 192.168.0.255, save and reboot your router.

If the admin console is working properly and simple programs can operate variables etc. I would try manually operating Insteon devices from the admin console. If that doesn't work I would do a link count of the PLM from admin console and if that doesn't work then buy a new PLM quickly.

It takes many different comms to talk between a device and PLM. The commands channels may be intact while the status coming back may be ruined from previous noise corrupting data while it was being updated. Then there are immediate response channels and query updates that all use their own codes.