larryllix

I had this happen with recent routers that wouldn't handle that many IP addresses for my extra IP addresses used for another 25 WiFi bulbs. ISY and polisy couldn't get an IP address from the DHCP server after power outages. I was in Mexico and ISY in Canada. After another $1K in routers etc.. I hope it is more secure. Routers like to get updated with bug fixes but then they add more features and the NVRAM was overrun and wouldn't keep that many IP addresses. Upon power outages it was a race for items to get their IP addresses and occasionally ISY994 or polisy lost out. When I got home, I found polisys was using IP address 0.0.0.0 to access my house items.

Don't do anything rash! UDI has no reverse-engineered all the Insteon things. This has only happened lately and Insteon hasn't put out anything new, except the selfish (Hub only) messed up version of the MS II. All the Insteon support drivers are already there and are not going anywhere. If Insteon revoked licensing from UDI they would likely collapse. Newbies are not going to buy Insteon modules for $40-$60 anymore when they are not available in stores where the dozen of other brands are for $10-$25 each. Insteon is only bought by people like ISY994 users and other that understand the value of the Insteon protocol system and will pay 2-3 times the dollars. For the time being, my Insteon stuff works fine and likely always will with UDI. UDI is slow with development but polisy will come...just much later than everybody wants.

ewwww... too many bugs in Chrome. I use FireFox and I am getting to like it much better. Many options like complete advert blocking and anti-snooping options. Google doesn't like it and tries to block the browser in some webpages. I have had to move some of my personal HA NRbridge software back to RPi from polISY. Since the upgrade to polyglot v2 my software started hanging about once per month after running in parallel with polyglot without problem, since polisy was released.

This paragraph is quite misleading. While true, it implies that the state of the if section must change logic. If the If section is true, and any line gets re-evaluated to true or false, whichever section is running will be stopped at the next time slice surrender point. ie. any Wait or Repeat program line, and either section, Then or Else, will then start to process at it's first line. The same process will happen when the Else section running. IOW: Whichever section is running, or none, is not relevant to the result from a new trigger event. The quoted text implies the result is related to what is currently happening in the same program. That is incorrect. Sent from my SM-G781W using Tapatalk

The variable method does look less messy, so I like it better, but it also doesn't reside in one place, making it harder to associate sometimes, but I have had trouble with variables in the past not being ready on time for programs to use them properly. OTOH: That may have been a quirk on some version that should have been corrected by now IMHO.

Run Program2 will retrigger Program2 every time the Program1 trigger happens anyway. It makes no improvement over the retrigger situation. However, if you use the disable/enable technique and set the program to "Run at Startup" it can be corrected after any power failure like this. If [enabled or disabled] [Run at Startup] some trigger Then Run (If) Program2 Else Enable Program1 (yes... self) When the "Run at startup" happens the If section may be evaluated as False and Else will run, and re-enable the program, whether disabled or not. If the some trigger is true at the "Run at Startup" time, Program2 will correct the disabled Program1 properly anyway.

Welcome to trigger based programming! This is expected behaviour from ISY994 programs. There are several ways to work-around this. Here is one. Program1 If someTrigger Then Run (If) program2 Else ---- Program2 [disabled] If --- Then disable Program1 do some stuff wait for timeout if desired enable Program1 Else -----

Yes, USB, Ethernet, or Serial port dongle. IIRC the polisy doesn't contain a serial port though driven by a "driver". The PLM is only a protocol converter, or type of modem. With three Ethernet ports the Hub could be used also.

Looks good except put your $porta_da_sala = 0 in the Tnen section after Wait 10 seconds . The Else may never run. I guess you may have noticed the $porta_da_sala (spoken terminology) will appear like a device in the Alexa app by now. Also, if you ever disconnect your accounts (Portal and Alexa) the Routines will still exist but have to be rebuilt to the variables. If you use the Notifications via ITTT (bottom of the selected actions) you can choose any combinations of speakers you like. If you choose too many it will become hard to understand, sounding like a lot of echoes.

In The ISY Portal you use the pulldown menu to acccess your Alexa "devices" Select a variable and then select a Motion Sensor below. You would then enter a 1 for "detected" and a 0 for "not detected". Make sure your ISY program makes the variable = 1 for about 10 seconds and then = 0. Never less than 30 seconds apart or the Alexa Routine will ignore your triggers. (anti-hacking) The name you enter in the ISY Portal Alexa chart will define the name of the pseudo device in the Alexa App you will find and use in the Routine.

Do you think the Alexa routines will ever be able to accept streamed text or inserted variable values?

Off-topic post was posted elsewhere??

Yeah. The province of Saskatchewan has gone to permanent DST, and Ontario will be doing the same if we ever get co-operation with Quebec++ province(s) and NY++ state(s). The DST will definitely need to be an accessible option for NY++ state(s) and many in Canada, if that happens.

They are settings to poll the light sensor for night time. Note the layout of the options is not very indicative of function. UDI did a lot of guessing and hacking to make the MS II work with ISY at all.

It is stated somewhere that ISY can only format to 2GB regardless of the SD card size. This has been a problem on many system over the years. You can format a card to 32 GB but once the system runs past it's addresding limit, the system crashes and then people blame the SD card and get a new one. The same thing happens again and again until the formatting matches the system and now knows when to stop. Sent from my SM-G781W using Tapatalk

You did not include any text from or enter a ping for Michel and he won't likely see your message.

Sure to break it down you would require a program to break it into separate flags and then we may as well just keep them all separate and use a trigger program like: If $sVar1 AND $sVar2 AND $sVar3 AND $sVar4 AND $sVar5 Then ..... Not as boolean person pretty but it could work

The total value 2^6-1 (63) can trigger a program. Wouldn't need any boolishness on the right side of the logical trigger. If $sBitTotal = 63 Then ....

The best way is to OR in distinct binary bits into the resultant flag variable. ie: OR in 1, 2, 4, 8, 16, & 32 from each program, so when the resultant bit accumulation == 2^6 - 1 then they have all ran and no multiple program runs can fool it. Let's assume the power never fails. ....The Bools

....or two ran and the second ran 5 times.

I would have each program increment a counter at termination and a 6 value trigger the last program dependent on the others, and clear the counter.

I would say yes they are saved in the backup. When you restore a backup file the init to variables are restored like is was part of the programming.

To further exemplify that I have a lot of lighting scenes, including WiFi device levels, and colours, that are dependent on variable values. If I ever restored a backup containing variable values my lights and some other devices would go to some previous value.

I don't use an Elk either but from the alarm panels I have used "Trouble" means the circuit is broken (EoL resistor is not connected or loop is broken) and "Violated" means the circuit has been tripped.