apostolakisl

I have used the webhook to open and close blinds and while testing did not wait but a few seconds in between and I had no issues. If I only use it on blinds, then it doesn't really matter since I would never change it back and forth in real life in less than 30 seconds.

How about that. I had no idea this existed. It is easier to setup for one item, but once you setup the webhook for the first item, adding more is just a matter of copying the network resource and changing the one digit in the URL. The webhook does let you use any URL delivery method in addition to ISY, though I suspect I won't ever do that.

I have discovered that there is a webhook skill for Alexa. The webhook skill allows you to create as many URL's as you want (I think there is no limit) and those webhooks's show up as devices in your Alexa according to whatever you named them on the webhook webpage where you created them. Once they show up as devices on your Alexa, you create routines where the webhook "device" is the trigger and then you set whatever action you want. In ISY, create a network resource plugging in the URL provided by the webhook. One issue I discovered here is that it seems you must set all this up from the primary account profile in your Alexa. I tried setting it up at first from my profile, but my wife is the primary account. Things showed up in my profile, but they did not work. When I set things up in my wife's profile, it all worked. Here is what your network resource should look like. In the path box, you put all of the webhook URL address that follows the ".de". In other words, the red stuff I put in the URL below. https://trigger.esp8266-server.de/api/?id=allofmyprivatestuff

Based on the other thread and this thread, the common theme here is that after the migration people had issues. The issues got fixed after a firmware upgrade, even though the before and after firmware versions may not have been the same. So I think there is some error in the migration that is corrected during a firmware upgrade, version independent. And now a "run at startup" will work correctly to set your day/night status.

At the time I wrote this I was working on the previous statements that there is a single program from sunrise to sunset. Anyway, using two programs needlessly complicates things since it won't do anything better than a single program and as you mentioned makes it impossible to assess day vs night status if ISY is not running at the time of the change from day/night. So yes, run at startup won't work.

@CoolToys Set the sunrise/sunset program to run at startup to avoid the status of the program/variable from being incorrect after restarts. It sounds like sunrise/sunset is now working? And yes, I had to go through when I switched to the Elk node server from Elk module and fix all of my Elk programs. However, I did not do that at the same time as switching to Polisy so it broke up things up.

EDIT: It see that Andy C posted in another thread and a second person also said they had issues. Both said issues went away with firmware update even though they weren't on the same firmware. Perhaps there is an issue with the migration and the issue gets fixed by a firmware update, regardless of the version. In other words, the update process fixes it, not the firmware. I am on Polisy 5.6.4 and have no issues nor did I have issues when I migrated to Polisy a couple years ago. Short of ISY having some glitch that is making the sunrise/sunset terminology not work, I suspect you have some other program that is doing this. Checking the current state of the night/day program and the state of the variable at any given time and seeing that it is as expected for that time of day rules it out as the problem. Again, watching the program summary page while you are doing things (or at the time it does things) that trigger these programs to run incorrectly will show you what program is doing it. Moving the sunrise/sunset line into your program instead of the variable won't fix anything. If the sunrise/sunset program is setting the variable wrong, it will be just as wrong if it is in the program itself. It is quite easy to see if the sunrise sunset program is setting the variable wrong by just looking at the variable value and seeing if it is correct for the time of day. Of course you can also look at the current true/false status of the sunrise/sunset program. Also, you can also do a "run if" on your programs and see if it the outcome is what you expect for that time of day and other conditions that may exist in the if clause. It looks @Andy C is saying he had the sunrise/sunset programs run wrong as well. I don't know, I have not seen this being an issue on the forum and I have had my sunrise/sunset programs work correctly through every firmware update over the last 15 years including 99i/994i/and now Polisy running two units at two different locations. It is unlikely that this has anything to do with the PLM. Orphan links can happen and can turn devices on and off as responders to other devices where they are not supposed to be linked. I see the chances of the behavior you described being related to the PLM or Insteon links to be very tiny.

OK, that fixed it. Thanks.

OK, you have a 994ir, not a 99ir

By "system" what do you mean? Polisy, the node server, my phone app? I have restarted the sensibo node and my entire phone. But not the entre Polisy. Also, it lists fan level in ud mobile as a number instead of word like "high"

The Sensibo node shows power state as 0 and 1 instead of on and off. The admin console shows the same node as on/off. Wondering if UD Mobile could be made to show on/off instead of 1/0.

There is no partial migration. You just set aside a few hours and do it. Of course if things go south on you and you are using the same PLM, you can quickly go back to the 99ir. Just plug the plm back in to the 99ir and reboot. Question, how are you accessing your 99ir? I am still using it as an ir receiver. Last I logged on about a year ago all was fine, but now I am unable as Java refuses to run the file because of expired certificate.

Hmm. I have the exact opposite experience. I have never had it not find my ISY or Polisy when on the same LAN/VLAN at multiple locations using multiple computers and evolving through a few different routers. However, this person also entered it manually and it isn't finding it.

Obviously if your ISY is showing up in the portal and you can get to it then ISY is alive and kicking. IoX will automatically find ISY as long as the computer running IoX and the ISY are on the same LAN and you don't have any fire wall rules in your router. It won't find ISY if ISY and your computer are on different VLAN's or completely different LAN's or across a VPN. Also I suppose it is possible that if you are running some anti-virus software on your computer that it may be blocking it. And as mentioned, your username when accessing via the portal is your portal username (likely your email) and the password is the portal password.

Well it is actually $49 for two years, but I guess if you never use it. Via the portal you can access everything including the admin console and thus you can write programs and edit programs and really pretty much everything remotely.

The portal gives you access to your ISY through via a secure connection through the UD servers. This means you can access your ISY from outside your home without opening ports through your firewall. It also allows you to integrate with Alexa, Google, and IFTTT. So without the portal, that is what goes away. But frankly, it is so cheap I don't know why you wouldn't get it.

@smokegrub Probably the unit failed because of capacitors. It isn't just PLM's that fail from caps. Of my original 2476D devices, I had maybe 15 that failed and I found that about 2/3's of them were fixed after replacing caps. It was kind of an exercise in "can I fix this" because I wasn't going to use them since I have gone all 2477D. Knock on wood, I have not had issues with 2477D units going bad. Maybe only 1 out of something like 60 of them. But I did fix and use the PLM's because I had no other choice at the time. And you may consider it since you have a device that I don't believe they make anymore.

I am running this on PG2 because it is my church and we have a 994i there and don't have any near term intention of getting an eisy. I have Sensibo set to F on the phone app, but the node is in C. I don't see any instructions for either PG2 or 3 on switching to F. Can I do this? @Athlon EDIT: I found in some q and a area that it is supposed to follow the units that ISY is set for. My ISY is set for USCS (United States), which seems like it should be F. I tried changing to British Imperial, restarting the node and admin console, and still the same. Changed back to US and still the same. I have it set to F on the sensibo app, and the "set temp" it displays is what is set in the app (in F). But the current temp displays in C and if I change the temp in ISY I am only allowed a range of C temps and all of them are well below the F temp you might want and so if I set it to say 25, the unit actually gets set to 61F (the lowest value).

I doubt the replace function will work since it doesn't typically let you replace an old device with a new one that is a different model. I think it let you replace the single band devices with dual band ones, but that is about it from my experience. You can try. First add the new device to ISY, then right click on the old device and hit "replace with". If it lists your new device in the options, then you can do it. But I suspect it won't. If it does, then that is all you need to do. ISY will move all the scenes and programs to the new device and delete the old device. The old device does not need to be installed for this to work, only the new device. However, you will likely have to add the new switch and rebuild all the scenes and programs from scratch. I suggest not deleting the old one until you finish adding the new one. Having the old one show up in all the scenes and programs is your guide to programming the new one the same. Once complete, delete the old switch from ISY by right clicking it and hit delete. EDIT: Also, the old device needs to be in the root folder to use the "replace with" function. If you have it in a sub folder, you first need to right on the old device and hit "remove from folder". Leave the new device in the root folder as well until replace device is completed.

@CoolToys I would say all you are doing is shifting your question mark from why does the program exist to why does the variable exist. You either have a program called "dark outside" or a variable called "dark outside". Both seem pretty self explanatory, but at least with a program you can put notes on it whereas a variable has not opportunity for notes. Either way, if you want to see its usage, you do a "find/replace" on your programs and search for either the name of the variable or the name of the program.

To help with confusion, you might start by completing uninstalling java and then install a fresh version from their website. This is sure to give you a fresh slate. Then download the IoX jnlp file from the forum and run it. Now any ISY's that show up there are local, alive, and real (not something saved). If you have a remote ISY, you need to login in to the portal and copy your portal url into IoX finder and save it. You will find it under the tab below and when you click on that tab one of the pieces of info is the url for the admin console that you need to copy and then paste into IoX finder after hitting "add" button. You can actually use that url for a local machine as well. Realize, your username and password for logging into the admin console via the portal is different. It is your user/pass that you use to log into the portal website.

You can do this if you want, but it just isn't necessary and adds clutter. The variable $sNight is just a mirror image of the program state itself. If you reference the program, it will behave exactly the same as referencing the variable but without the extra step. If $sNight = 0 (if you used 0 for night) is precisely the same as If program Dark outside is true The state of a program that sets a binary state variable is indistinguishable from the state of the variable that it set. When the program changes state, it will be a trigger, when the variable changes state it will be a trigger. Both only have two possible states, day and night.

I see sensibo is on pg2, so problem solved.

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).