larryllix

No gibberish but just another poor attempt at AI (guessing) what was asked in lieu of knowing about any devices. It was a very weird experience. I had to install an Insteon wall switch, which I wanted to do some day anyway, that gave me Fast On/Off, Dim up/down, and third tap capabilities to even control my lights via ISY program logic and wizardry. Dependent? Definitely with mostly all WiFi lighting. I had no idea until now.

I discovered a new switch in the ISY mobile app that enables/disables the account permission. This seems to have coincided with my using "Sync" with my polISY in the mobile app. It seems it installed defaulted to disable. I am guessing the "geographical restrictions" was a generic message applied in lieu of more detailed error reports, as programmers tend to do, until the fine polish is put on their programs. After allowing the mobile app to allow permission the accounts connected again and all devices seem to be working fine after a "Discover" via Alexa. Thanks.

Paul is referring to the Insteon device, not the PLM. Every Insteon device should be factory reset before connecting to the EISY via PLM. It avoids a lot of troubles later on. After factory resetting an Insteon device you can use "Restore" to refresh all the links already set up in EISY or if not installed yet, install it as new. Right click on the device in the device tree to see options.

@LeeG I had the idea he may have wrote the low level code to I/F with the PLM. He knew the Insteon codes too well. He was our guru and we miss him.

It's an AI clone!

Just for the confusion that may happen here. The thread subject matter shifted to order of operations of program lines. I think we killed the order of operations of programs, again.

This is still an issue (next day). I tried some of the old tricks, including resetting every device's location, removing the apartment number, to comply with the suggested location address, changing the country to US, etc.. Skill still is not allowed to be enabled "due to geographic restrictions". This also happened years ago, when the skill was first being developed, but has worked without problems for many years, until yesterday again. Based on the sudden nonsense answers Alexa gave us for most device control attempts, this appears to be an amazon bug, so far. Contact with them has been unfruitful, so far.

@bmercier My Alexa speakers suddenly have started to spout nonsense to me. When asked to turn on all lights, it responds with I don't have any spaghetti. This seem to be only ISY relate topics. After many trials to repair this I finally unlinked the ISY Portal account from Alexa and when I attempted to reconnect it it tells me I am not allowed to enable the skill due to geographic restrictions. I have gone through the setup of all my Alexa speakers and standardised my location exactly the same. Any ideas?

Yes, I remember the conversation about order of execution a year or so back, and after some testing I found to be nonsense on my system.

You are only editing the IoX copy of the programs so the changes need to be installed into the ISY machine. Now I am beginning to wonder if the method of updating variable names and values has had the same logic applied to them, where you now need to save them also. That wasn't the case a few versions ago but you may not find them in the pulldown menus of the program editing page.

Each element that can cause triggers likely has a list/stack of other elements to check should the value change. There is no looping required. IIRC, spread sheets did this looping for value changes. Of course there may be a background looping algorithm, as we know the code exist anyway, for power up conditions, where there are no triggers happen to update the database.

I think the IoX Launcher must fire out a generic "are you out there" packet and any ISY machine is supposed to answer. Sometimes the router isn't ready on time. I had a lot of problems with fast power blinks where equipment would see the power blink and re-initialise but the router would not, and not ask for any equipment to report in, for registration in the DHCP table.

Agreed, but the Else redirect is required if a Control On off is present in the If section. This avoids further program usage to permit [Run at Startup] to function since, as you above logic, a Control X condition will never be true unless that event called the evaluation. Run at Startup would always evaluate False and run Else, and not start any looping program lines.

There is likely an order to processing and I have good idea what that may be but it could change in any future version so it must be considered undefined. If a particular order is required then it must be forced by the user using Waits or Repeats and or with semaphore techniques.

I hear you! Even though most of the spy style softwares can be disabled the latest trick eveyone is using is "For our security, we have forced another update on your working system so we can install new features and new methods of disabling everything. Of course, we have turned everything back on, so you can experience the same amount of time we have spent, attempting to force these spy features on you one more time. We know you are disabling these items and we are watching you"

I have been holding off on anything Matter. I have a few dozen Insteon plug-ins that I will never use now. I started on Z-wave buy a z700 dongle and a few plug-ins but once I saw the 1990s style interfaces incorporated into ISY and the poor quality system complaints, some of my new units have never been out of their boxes. The Matter implementation is over Ethernet via LAN so I haven't seen any reason to make any jumps to it until the clothes come out of the wash totally clean. Most of my lighting is multi-coloured RGBWW/CW WiFi bulbs and they work very quite well without any cloud connections at all. Of course my 18-20 bulbs are getting to be 6-8 years old now.

If I need to force Then to run on [Run at Startup] I use an Else line to redirect. If xxxx control switched on Then need these lines to run at startup Else Run 'this program' (Then) Of course there is always some instances where this isn't possible. This technique is good for lights that need to turned off and complex multi program logic that may need to be reset.

Rethought logic

I have never needed to operate my ecobee via voice control. However, I have used the webpage controls to modify settings and set it up. That takes cloud access. I am not sure how secure their comms are with the stat, but it can't be any less secure than all the VPN personnel, people are giving full control of everything in their house to. I have set limits on my ecobee stats and a few watchdog ISY programs to monitor ridiculous settings, so the worst attack should be an attention getting cool or warm spell in the home. Ecobee stats have those limits that can be setup under password control lock. Previously, I did setup a low security home monitoring system with arm/disarm control via Alexa voice. However, I used a double command sequence, along with a time window allowance, to make it more secure. More intelligent hacking would not be likely, for the benefits gained.

Just call program2 from program1, and if you don't want program2 to be self-triggered just disable it. Enable/disable of any program only affects the If section triggers. The code will still run and the conditions will only act as conditions/filters. However program1 will not wait for program2 to return. All programs surrender their current time slice to the ISY executive logic engine, and I/O handlers, when encountering a Wait or Repeat program line, to be continued when the system "gets the chance" at the end of the programmed Wait or Repeat time.

ecobee is a cloud monitored system (not cloud dependent) and very well done NS, and device. I have owned many different brands of stats in my life and ecobee has been the best one (I have owned three now) I have ever experienced. However, the units having Alexa installed in them have been complete failures. You can't put a microphone flat onto a wall and expect it to understand you properly. Alexa manuals also tell you that. I also find the remote sensor idea is a complete failure. I have three remote sensors and leave them all disabled after a about five years of experimenting with them. Silly idea without a door closed sensor to change it's personality.

Yeah. I am a dedicated Insteon person but the old Insteon made some real garbage. I had two 2441WTH stats and one never worked from day one. UDI support pointed out that when sending a command the more recent 2441-WTH model was acknowledging the request but would never react to any commands. It became a probe only unit. Should have been 2441-WTF. Warranty? Sure but I had to pay the shipping from Canada across the border for about $65. The earlier model worked OK but the 3c = 5F dead-band was intolerable for us, freezing draughts at some times and heat waves of sweat the next hour. I dedicated that one to simple ventilation in my cold-cellar to control humidity. Again...Bad Insteon! I hope to keep hearing more responsible engineering from the new Insteon. They need to change their name to Insteon2 in they want to circumvent some of the bad taste so many users got in their mouths from the last idiots. Still a good (possibly the best) system and I wish the new owners all the best.

Been awhile since my MS 1s were not packed away but this brings back memories of them (I had 12) producing random On_s when the batteries were low. Bad Insteon...bad!

If you call the program (If, Then, or Else), previous execution will be cancelled as soon as it encounters a Wait or Repeat command line. There is no threading/multitasking of a program. Run at Startup will execute the If section and consequentially run Then or Else. The program will self start after power up at 7:00 AM and 10:00 PM and run Then or Else respectively.

Each device needs it's own program eg. If device sends control Off and time is sunset to sunrise (next day) (or nightime variable) Then Turn device on Else --