apostolakisl

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.