apostolakisl

Turns out Amazon is better for just one unit. $99 and then a $10 coupon is applied at checkout plus free shipping makes it $89. Sensibo is $85 plus $15 shipping if you only buy one. If yo buy multiples, you get free shipping though. I just bought one. This is for my church, and I don't have PG3 yet there, so now I am going to have to do that. Can you put PG3 on a rpi? I have PG2 running on a pi there already.

That is great info. I was unaware of these and had given up on integrating mini splits with ISY. Which sensibo unit do you have? They have several and it is a little ambiguous as to which I would really need. Basically, I just want ISY to be able to see the current temp and control the set temp as well as state (heat/cool).

Minisplit IR remotes from what I have read are not hackable in any reasonable sort of way, plus you wouldn't get the status updates back to ISY. I have a minisplit at my church and looked at getting ISY to control it and it didn't look good. So this means 24v adapters and one of the brands you mentioned. Those thermostats usually run around $250 which is where my estimate came from. Not sure about z-wave thermostats that would be native to ISY rather than a node server. Something like this https://www.amazon.com/Honeywell-TH6320ZW2003-Thermostat-Comfort-Control/dp/B07HFL7R44/ref=asc_df_B07HFL7R44?tag=bngsmtphsnus-20&linkCode=df0&hvadid=80608063550902&hvnetw=s&hvqmt=e&hvbmt=be&hvdev=c&hvlocint=&hvlocphy=&hvtargid=pla-4584207589933379&psc=1 might work and be much less expensive. I can't confirm if it will be recognized by ISY and populate with all the right nodes.

Network resources are executed from programs, not scenes. For example, here is a program I have that closes my blinds via a network resource when I arm my alarm to night mode. Blind Control - [ID 008E][Parent 008A] If 'Elk' Armed Status is Armed Night Then Resource 'IFTTT blinds close' Else - No Actions - (To add one, press 'Action') I don't own any MS6 devices to tell you exactly what the if clause would look like. But if it is like my insteon motion sensor it would like this using the "control" program language: And you definitely do not want to use the language "has responded" in a program. There are almost no situations where you use that. And programs are executed almost instantly. ISY does not (of its own accord) poll devices, it is an event based system, not a status based system. In the above example, if I walk into the pantry, the pantry MS will detect my presence and put out a "control switched on" over the Insteon network. The PLM and by extension ISY will respond essentially instantly to receipt of the message and execute the program. The network resource will hit your LAN again essentially instantly and after that it is up to the device receiving the IP packet as to how quickly it responds. In my case, there is a couple seconds delay that is variable depending on how busy IFTTT servers are. IFTTT if you are not aware is an online service that connects all kinds of different systems together using If This Then That (IFTTT) construct.

Did you have a backup of your ISY994? Hopefully yes. You should be able restore that backup to EISY and have most systems functioning again. Depending on how you had the IP address assigned you may need to do something there so that EISY is on the same IP as before (only necessary if you had other devices set to talk to ISY at its IP address). There may be issues if your backup (assuming you have one) is on a somewhat distant firmware version. But regardless, restoring the backup would be the first step and then you would implement any corrections that may be needed after that.

If you are getting the 24v adapter and standard smart thermostats, what is it you are needing? There are several brands of smart thermostats that have node servers, If you pick one of them, you should be good. Though I would be surprised if you ever came close to recovering the cost of buying 8 smart thermostats with electricity savings. I would speculate you are spending $2000 to get 8 smart thermostats plus whatever the 24v adapters cost.

Just know that if you used an integer variable for $night that it will not be a trigger where "from sunrise/sunet" statement is a trigger so it will behave diffeently. If you use a state variable, it will be identical. I would also suggest you use the naming convention of placing an "i" on all of your integer variables and an "s" for state. ie $iNight or $sNight It is helpful for yourself and also when you post to the forum with questions everyone will know.

The question is do any other programs run. You know that one runs correctly because you put notifications in the "then" and "else" clause already and tested, as I believe you stated a few posts ago. If indeed you received the correct notification showing that the correct clause ran, then it is something else that is turning the light on and that is what you need to look for.

The quickest way to find out is to watch the program summary page while opening the door and see which programs trigger. Click on the "last run time" column to sort by most recent run time.

@CoolToys I understand your use of variables, I usually use cascading programs instead for that, often having program 2 disable program 1 and then reenable it when complete. However, there is still no need to convert "dark outside" program to a variable. Since the state of the program works exactly the same as the actual sunrise to sunset clause, anywhere you used sunrise/sunset clause, the dark outside program status will produce identical results.

@CoolToys You don't need any variables. You just use the true/false status of the program dark outside (see my example). You would only need to use a variable (an integer one) if you didn't want the sunrise/sunset times themselves to be triggers. Mostly this would be the case if you have items in your "else" clause that you don't want running at sunrise/sunset times. Whenever you "and" sunrise/sunset times to another condition (either through a dark outside program or directly in the program), getting triggered at sunrise/sunset won't matter provided the else clause is empty. Using a "Dark outside" program like I did works exactly the same as putting sunrise/sunset times in the actual program, but it is simpler if you have a bunch of programs that use sunrise to sunset (or vice versa) logic since it is now just a single line. Sunrise/Sunset times are triggers when in a program, and a program changing status is also a trigger when that status is referenced in another program. So it is the same exact behavior. If you got the correct notifications of the program running true/false, then you must have some other program or scene doing something.

@CoolToys Changing the order of the conditions when they are all "anded" will not have any affect. I would start with adding an email or text notification to your "then" and a different one to your "else" and then you will be able to follow the program's every execution. This will confirm if it is running incorrectly. If indeed it is running incorrectly, which would be a new one for ISY, I would delete the sunrise to sunset clause, save it, then re-add that condition and save again. I also have the Elk node and I have a Polisy, while not eisy, it is still running the same code. I do not use the sunset to sunrise in individual programs. I have a single program called "dark outside" that just says from sunset to sunrise the next day. It has no then/else clauses. Then all other programs that I want to only run while it is dark outside simply reference that program's status as true or false. This works. I have a number of programs that perform the same function. Below is an example. Patio Door - [ID 000F][Parent 0013] If Program 'Dark Outside' is True And 'Elk / Family Rm Door' Logical Status is Violated Then Set 'Family Room / Patio-FamRm-Fans Coach Lts L' On Else - No Actions - (To add one, press 'Action')

All good info, but I would also like to point out that the "if status light off" element of the program isn't needed at all. If the light is already on, and you send an on command to it, big whoop, nothing happens. You would only need that line if say the light being at some partial level of on meant you wanted it to stay at the level and not turn all the way on when the door opened.

Yes, indeed. This would make looking at the last status of the program ineffective. You can always add a line in the then clause that sends you an email or sets a test variable. I don't know what the variable that is already there is doing and what other programs might affect it so not sure if you could use that. You could also add a line in the else clause that does similar. In summary, I really don't think this program is turning the lights on. The only other thought is that the ISY clock is set wrong. I really doubt ISY is having a logic fail like this.

I can't explain your issue. Since all "if" statements are "anded", then any of them being false would make the whole thing false and it would run the "else" clause (which of course is blank). Please confirm that this actual program is what is turning on the lights and that you do not have another program lingering somewhere that maybe you were working on and forgot about. If you look at the program tree, the program will have a half red icon to the left of it if it last ran false and half green if it last ran true. The program summary page will also list it along with last run time and true/false. Try opening the door, then sort your program summary page by time last ran and see if some other program ran at that time and turned the lights on.

You just right click the primary node for the KPL in the main tree on the left of the main screen in the admin console and click delete. Then you factory reset as per usual. The you add it back per the normal routine. Put ISY into Insteon linking mode and push the little set button on the device.

During the restore process it would give you a similar error if it failed to write to the device. Your KPL might just be bad, but again, I would try totally deleting the KPL from ISY, then factory reset, then add it back to ISY as if it were a new device.

If the restore progressed without errors, then the PLM must be good. Can you query the device from ISY? You might try completely deleting the device from ISY, factory reset, then re-create the scenes from scratch. Be sure to document all the scenes exactly. I take screen shots of all the scenes to help with that.

I would start with a factory reset and then restore from ISY.

Seems I answered my own question. Indeed, there is a separate node for heat/cool state that is not listed on the summary page. It is found in programs under status/thermostat name (just the name, not cool ctl or heat ctl which even though they are control functions still have a "state" which is always the last control command received by ISY and can not be corrected via a query).

I have a bunch of Venstar thermostats with Insteon attachment at my church. I have noticed an issue where the HVAC unit will be in one state (ie cooling) and it will say it is cooling when you look at the device in the admin console. But when you click on the folder and see the page that lists everything in the folder, on that page it will say the unit is off. In addition, programs that should be running when the device is cooling will not be running. If I shut the unit down, then turn it back on, it will then be correct. This is sporadic and happens across the board on different units seemingly randomly. Below are the pages I am referring to. Now at this time, the pages are in agreement, but a few minutes ago they weren't. I had to shut the unit down for a minute and turn it back on, now they agree. Prior to that, the summary page showed "off" as the cool control current state for unit "upstairs south". But the device page showed "cooling" in the heating/cooling box. And indeed, the unit was cooling. Are there different nodes for these things even though they seem to be the same node? I have noticed that sometimes the "control on" command is a missed com to the PLM, and because of that, I have ISY set to run queries of the units every 15 minutes which corrects the device specific page to say "cooling" or "idle", but it does not correct the summary page and it does not cause programs that look for the state of the unit to run. Here is my summary page: Here is my device page

Nodelink works a little different. It is installed into ISY as a single node, however, you can have lots of sub nodes under that single ISY node and they all show up in ISY tree as if they were separate nodes (but under the "node servers" tab, it is just one node). In my case, ISYlink (for whatever reason the name on ISY node server tabs is "ISY Link" instead of "nodelink") it is node number 1. I currently have 3 nodes running on nodelink, 2 of which produce heartbeats (CAI webcontrol and DSC alarm). There is no setting to disable the heartbeats as far as I can find. I also have nodelink running on a 994i at my church. I have never had any issues with it. That ISY is on 5.0.16c firmware and has gone without a reboot now for almost a year and runs perfectly. I have had nodelink running for many years (probably going on 10) and I am not aware of any updates to nodelink in a very long time. Nodelink predates the existence of polyglot by quite a long time. This problem on the other hand is quite recent, just in the past few months, which makes me curious how something that didn't change would now change its behavior. The problem is also hard to predict. It has not happened now in almost a month. Prior to that, it went a couple weeks. Right after the most recent event, a new version of the polisy firmware came out and I installed it. So I don't know if that has anything to do with everything working now for a month. I do not know much about sockets. I assume there is some back and forth acknowledgement? I suppose an outsider requests a socket, and the ISY grants it. But is there an acknowledgement? Does the outsider get confirmation of an open socket and then continue to use the same socket? Does the outsider just send whatever packet it is sending and then close the socket until the next time it has data to send?

Sorry, not sure what you mean. If nodelink is connected it alternates the value of "heartbeat" value free 1 to -1 every 30 seconds. If heartbeat value doesn't change that means the node is either not working or not connected.

@Geddy Win10pro Interestingly, for the last few months, I wasn't able to use IoX either. I have to use the java console you access from ISY itself. And then after this update, java just wouldn't open at all. And just now, windows is showing another update. UHGGGG!

I wanted to share this in the IoX launcher, but it is locked. I was getting this error after doing a windows update, java update. I did the usual clearing of the temporary files/applets. Still go the error. Tried using windows control panel to delete Java and resinstalled from the Java website, same story. Unchecked and checked keep temporary files box and still. Finally, I fixed it by using the Java website's uninstaller and the offline installer. https://www.java.com/download/help/troubleshoot_java.html Perhaps this may save someone some time in the future.