apostolakisl

That would be perfect to use my basic idea. If you have a few failed pings in a row, reboot. You could just ping 8.8.8.8

A site to site VPN with IOX updating variables to each other plus no changes to a cloud PG3x would rule out an isolated PG3x or VPN issue. If both PG3x and VPN are down, then it is almost certainly and internet issue. You could set it to only reboot if both were down. If $state.variable.updated.by.remote.Iox.is 1 (set this to update via Rest command sent from remote Iox every minute or so between 1 and 0) or $state.variable.updated.by.remote.Iox.is 0 or weather PG3x node is not -50 degrees or weather PG3x humidity is not 100% Then wait 30 minutes send notification "about to reboot router" (if you get this email, presumably both your vpn and your PG3x node are down) wait 10 minutes set appliance link off wait 10 seconds set appliance link on wait 10 minutes send notification "router rebooted" The program will keep re-triggering true every time any of those things changes so it will never finish the 30 minute wait unless all of them stop updating. Alternatively, get yourself a modem/router that actually works. They do exist, I have never had to reboot mine in years, home of office. Only reboots are when I am rearranging plugs or something. They are on UPS.

I have a VPN between two sites and I have some items that PG3x controls on the other end of the VPN. If that heartbeat goes down, I have it send me an email. This works very well to tell me if the remote site has gone down or the VPN has gone down. Now if you put an Iox at both ends of the vpn, you could heartbeat between the two devices. If the heartbeat goes down, you can have both of them send you a text/email (obviously only the one still connected goes through) and it reboots the router via an appliancelinc. I would put a delay in there of like 30 minutes or more to give you time to react to the text to block it from rebooting the local machine if it is the remote one that went down. You would need routers at both ends that do site to site vpn. I use ubiquiti stuff which is insanely easy to setup site to site. You also need a public IP address at one (or both) of the endpoints for Ubiquiti site magic to work. If you have CGNAT at both ends, you will need to do something like tailscale and rpi's at each end. In short, I wouldn't bother with this if I had CGNAT at both ends.

If I had this issue I don't think I would do a scheduled reboot. What if my router hung up and the reboot wasn't for another couple days? I would use some node servers that rely on a cloud connection. Something that regularly changes. For example, use a weather app. If the temp and humidity stay exactly the same for like an hour, reboot the router using Insteon. Maybe just to be sure it isn't the weather app that went down, use two different apps both of which have values that get updated every few minutes. If neither changes for an hour, reboot. The only caveat here is if PG3x is somehow down. But I would add to the mix an email notification telling you it has rebooted. At this point you can manually check it out. Obviously, if it is pg3x that is down, you will still be able to access your ISY remotely and ISY will still be able to send you an email remotely. Perhaps two notifications, one that sends before the reboot and one after. If you get the first one, you know it was an unnecessary reboot and to figure out what is up with PG3x.

In my experience, these things usually are a link table error. Unless things are super complicated, I usually just delete the scene and recreate it. Next step is to delete the devices and readd. Finally, the admin console opening up showing the last device added every time is a bug in the recent firmware. You need to reboot your iox to get rid of it.

One of mine updated. Also got a new voice that we changed. It has been several weeks and I have no problems. I find it better in fact since you no longer have to say things exactly as scripted. You can talk to it like it were a person using variable words, word order, and can add extra words. Like , hey Alexa, can you turn on the patio kitchen lights?

UD is building a browser based configuration tool now that is hosted directly on polisy and eisy. Every month or so they release a new version that adds another layer of control, but it is not a full replacement yet. Also, UD mobile (Android/Iphone app) hosts many configuration features.

I had a fried SSD and had to replace it. I flashed the image that Michel gave me, but it turns out the drive only got formatted to slightly bigger than the image leaving most of the ssd unformatted and incapable of taking any further updates due to insufficient space. I had to figure out how to repartition the SSD. It wasn't terribly hard, but it was something I had no idea how to do since I had only ever worked with PC hard drives. If you need to do it, I believe I posted how I did it in the forum. EDIT Here is how to do it.

Same here. Some bug in the firmware now causes newly added devices to keep giving you the pop up every time you open the admin console. Solution for me was the same. Reboot. @larryllix @bgrubb1

Too bad because otherwise they were perfect for my needs. They were very compact and kept a fiber to ethernet converter, small switch, and VOIP modem running all day long when new. I assumed they used crappy cells, but I guess it was the assembly?

Unless they cheaped out, the power supply should be PD3.0 meaning that it doesn't deliver power until after it first does a data link to the device and establish what voltage is requested. Maybe I'm wrong, but that is how I understand it. Perhaps it might deliver 5v if there is no PD3.0 data connection established. A USB C power supply that just spits out 12v no questions asked would be a dangerous thing. And obviously your USB C to barrel connector could also be a dangerous thing depending on what voltage you plug into the barrel and what USB C device you plug it into. I do like the UPS's that just do the AC to DC conversion and output the UPS directly to DC. I would caution folks about the brand Talentcell. I bought one, it worked great, so I bought more, 10 in total. Well, they all failed in less than 2 years. Complete waste of money. https://www.amazon.com/dp/B07WLD32RP?ref_=ppx_hzsearch_conn_dt_b_fed_asin_title_44#averageCustomerReviewsAnchor

A ticket seems to be needed. But in the meantime, check your router and see what IP and mac address show. You can then manually enter the IP in iox finder and use port 8080. Http://xxx xxx.xxc.xxx:8080. Assuming a brand new eisy it should login with admin/ admin. If memory serves, the backup restore will not tx your password so you'll want to set that. From there you can restore your 994i backup to it. You should be able to register it to your portal account and tx your portal subscription.

Benoit tells me that the contact closure (and I assume motion sensor) methods of triggering a routine in Alexa have a UD built-in "debounce" that blocks changes in the variable from being propagated to Alexa. He didn't say it was 30 seconds, but if it isn't 30 exactly, it is real close to that. UD is concerned about API request limits set by Alexa. I don't know if the API issue is per Alexa account or if it is for all API requests from all UD portal users. If it is the former, I would prefer that UD just gives you a warning not to overdue it and if you do, it is on you.

Benoit said if you are using the eisy ui to log out and log back. I did the switch profile first and it worked. Although I swear I logged out of the portal and back in, but perhaps I did that from the portal itself not the eisy ui. I don't recall. I am not sure how this all works with logins being registered to what since both eisy ui's (in my case), the portal itself, and possible one admin console can all be logged into the same portal account on the same pc.

Webhook URL is setup in a network resource which can only be activated by a program. Variables need not be involved. Variable/contact closure => Trigger a routine (about 1 second) Webhook/network resource => Trigger a routine (about 1 second) Insteon Light exposed to ISY can not trigger a routine and isn't part of my discussions here.

Not sure what you mean. Faster than using webhook? Both network resource/webhook and setting a variable/contact closure work about the same on the initial trigger. Roughly 1 second. The webhook is dependent on the hosting server response time plus internet latency (to Germany). Similarly, using the variable method is going to have some latency based on ISY portal latency as well as internet latency to wherever ISY portal is hosted. Both would presumably be equally exposed to the same Alexa server latency. But when you use the variable/contact closure method, you are dead in the water for the next 30 seconds. The webhook method is ready to go right away for the next trigger. Also, unlike a toggled variable, with webhooks, you can keep triggering the same routine repeatedly without a toggle event. For example, say you had a routine that triggered a bell to ring. You could keep sending the webhook that triggers the ring over and over. Compared to a contact closure, you need to go 1, then reset to 0, then 1 again, then reset to 0, etc. And because of the 30 second delay, you would be limited to ringing the bell once per minute. variable 1=ring, wait 30 seconds, reset variable to 0, wait 30 seconds, variable 1=ring again. Obviously there is a limit to how fast you can get a webhook and an Alexa routine to respond, but you could probably repeat once a second. You also have to consider the response time of the routine target. If it is an Insteon light for example it has to get from Alexa server, through the ISY portal, to your ISY, through the ISY and then through the Insteon com.

So I did some playing around. I used a variable exposed to Alexa as a contact closure and an Insteon light also exposed to Alexa. I set up two routines where toggling the variable between 1 and 0 turns the light on/off. Changing the variable gives you a very quick response, perhaps a second. HOWEVER, the contact closure appears to get locked out for 30 seconds or so. So toggling back and forth in less than 30 seconds will present delays. Should you change the variable before 30 seconds expires the routine won't trigger until the 30 second lockout window has passed. If you change it during the lockout, and then change it back before the 30 second expires, nothing will happen at all. I can see where this time-delay would be desirable, but it makes no sense to me to make it the default. Alexa lets me use the webhooks repeatedly pretty much as fast as I can send them to it.

What do you mean by that? I have a bunch of these and they work 100% of the time.

As far as I can tell, the only way to use the portal for ISY to signal Alexa is to use either the motion sensor or contact closure variable setup. The "spoken" in these cases I think is irrelevant since Alexa only responds to the state of these variables, it doesn't control them in any way. Anyway, after all my screwing around to get the variables working with Alexa, I am going to stick with using the webhooks. The webhooks always work in a second or two. I am using them for a few things including opening and closing my Levelor blinds. If you push the button to close/open the blinds and then 20 seconds later they finally do it, well that stinks. My wife would certainly complain and this would just be something to try to explain to guests, well if you want the blinds closed push the button and then sometime in the next 30 seconds they will do it.

I finally got this working. Benoit at UD gave me all kinds of suggestions, none of which worked. He said all looked fine on his end. I called Amazon customer support and actually got a person. After 90 minutes on the phone they got it to work. However, I have noticed it is not fast to respond. I have it on contact closure and sometimes it takes 20 seconds or more to respond. Fastest I have seen is maybe 3 or 4 seconds.

I did a ticket and they said the token had expired and I needed to click on "switch portal profile" which renewed the token. Apparently if you have two ISY's on the same portal account, the token can expire on one and not the other even though they are both on the same portal login (my other ISY/PG3x was working fine the whole time). Apparently logging in from different computers and rebooting ISY doesn't renew the token. "Switch Profile" was the necessary step. Never would have figured that out on my own. And the token only applies to the purchasing part of the PG3x admin console.

You do this by using the "command" feature in the favorites. Start by hitting the plus to create a favorite Under type, select "command" Select the display node as you wish Select the "add command" at the bottom (it will tell you have to save first, go ahead and click to save) It opens up the command config page. Select the programs option and whatever program and whatever you want the program to do. You can also further customize the display node by using configure advanced options and have it be different colors and stuff depending on the state.

Running 6.0.4 on Polisy. I open PG3x console and navigate to the store, open a node, click "install" and nothing happens. Nothing, no errors, nothing. Tried multiple. I navigate to "purchases", and it forever says "retrieving purchases. . " I rebooted Polisy I tried from both the 3000 port as well as using the Eisy UI interface. Same story.

The whole purpose of having the light status in there is because CHANGES in light status will then retrigger the program. That is what you want, as soon as any of the 4 lights finishes its countdown it will change the light status and then disable itself taking it out of the mix. But when its light changes status, it will retrigger the remaining programs that haven't finished and start them over. You will start with 4 programs running, then 3, then 2, then 1 then none. If you really want to be 100% sure this works, use two status clauses for each light since the light can't be two status' at the same time, it will always trigger true. ie If light x is not 1% or light x is not 0% The above if clause will always run true any time the status of light x changes. EDIT: Another way to do this is to use the true/false status as a retrigger. Have each program where the countdown runs to zero, run its own else clause to change it from true to false. Then the other programs will all retrigger on it. Program W If time is sunset or program x is true or prgram x is false or program y is true or program y is false or program z is ture or program z is false then wait 10 seconds repeat while $iW is > 0 $iW = $iW - 1 wait 1 second repeat 1 time turn on light w run else program W Else disable program w So the above program would be duplicated changing out the variables as appropriate for each of the 4 (or more) lights. All 4 programs would run at sunset. The program that finishes first will become false and disable itself. The other 3 will retrigger when this program turns false. Then the process repeats starting with the 3 remaining programs . . .then 2 . . then the last one. EDIT: I actually wrote the program in ISY and copied it to here. Program W - [ID 0001][Parent 0093] If Time Is Sunset Or Program 'Program X' is False Or Program 'Program X' is True Or Program 'Program Y' is False Or Program 'Program Y' is True Or Program 'Program Z' is False Or Program 'Program Z' is True Then Wait 10 seconds Repeat While $i.zW > 0 $i.zW -= 1 Wait 1 second Repeat 1 times Set 'Light W' On Run Program 'Program W' (Else Path) Else Disable Program 'Program W' The above program will run at sunset (making itself true). wait 10 seconds, count down the variable, turn on its light, change itself to false, and disable itself. UNLESS, one of the other 3 programs beats it, in which case the other program will turn false before this finishes. That will re-trigger this program and it will start all over from the beginning.

I wrote this program and can confirm it works. Every time I do a "run then" command on it, the 4 variables get randomly assigned a 1,2,3,or 4 with no two being the same. I used 4 here because it proves it works. But you can just as easily make it 30 or whatever. Since you already get the countdown method, then that shouldn't be an issue. Regarding the time allotted. Just figure out what the max possible is. So for example wait 10 plus some random amount between 0 and 30, then the max for each run is roughly 40 times 4 or 160 seconds. So give yourself 3 minutes. Finally, you need a program to do a "run then" on the program "Random" I wrote below. Like If time is sunset minus 10, run then program Random. Random - [ID 0089][Parent 0093] If $i.zW is $i.zX Or $i.zW is $i.zY Or $i.zW is $i.zZ Or $i.zX is $i.zY Or $i.zX is $i.zZ Or $i.zY is $i.zZ Then $i.zW = Random 4 $i.zX = Random 4 $i.zY = Random 4 $i.zZ = Random 4 Run Program 'Random' (If) Else - No Actions - (To add one, press 'Action')