apostolakisl

I see this error. And have exclamation points. ????

Probably need to replace them. Are they dual band or the old ones? I had problems like that with the old single band units but have never had a dual band fail. I have 100% replaced my old single band devices with dual band. For fun, I tried replacing the capacitors on my failed single band devices and most of them worked again. That might be more trouble than it is worth. You can probably pick up some used dual band units for $30 or $40.

Just get a VPN and don't worry anymore. I assume that big brother in Canada isn't blocking VPN. And I would have to ask my kids about Netflix, I never watch it. Oh, wait, just remembered, I had insomnia one night and watched 5 episodes of "Never Have I Ever" and there were no commercials. Yes, I am as embarrassed as you might expect about that. But it was narrated by John McEnroe, so I should get a pass for that.

I know it is possible to block service to certain IP ranges. but I don't think Canada is blocked. Based on some threads on Google's website, it looks like they do not block connections over GV to Canada IP addresses. In fact the Google rep suggested to one person to buy an OBI200 unit to use GV in Canada as a VOIP service. I used GV over IP on my phone all over Greece and The Netherlands this summer.

The GV email to text works great and is basically instant. I like it because it shows up across all of my platforms simultaneously. The downside is Tasker can't read them, parse them and act on them like a native text. But now that Tmobile has gotten so unreliable about delivering email to texts (sometimes taking hours), the Tasker profiles have become useless. Regarding Michelle wanting the timeout set to 10seconds, that is fine, I don't care about a few seconds, but they should change the default to 10 seconds then. Like most people with an ISY, you can't be expected to read all the threads on here, so how are you supposed to know it should be 10 seconds? Especially when 1 second has always worked fine and is default. You have a problem and you waste a bunch of time not knowing the root cause. The issue is not waiting a few seconds, the issue is it doesn't work at all and you don't know why and you futz around wasting time and effort and get frustrated.

GV works anywhere you get internet, though I assume you are correct when you say there are no Canada phone numbers. Might not matter if you have a US phone number since I think for the most part calling back and froth from Canada to US is free. To a large extent it doesn't matter since GV mostly works over IP. I was just in Europe and had no issues using my GV number there. But, in short, I don't know what your original question was about the random address. When I use GV it shows it came from my phone number when I send from ISY linked to GM. When I send from ISY email to text to my phone's native number (@tmomail.net) it shows up as having come from me as well. I believe it sees the email address and looks it up in my contacts. Perhaps you are using the default ISY server? When I use the ISY default it always showed as coming from "alerts@universaldevices.com" Anyway, I don't have issues with GM working on the ISY now that I switched to 3 seconds timeout. Same with the using ISY default. I have GM set to 2 level authentication so for outside apps to work you have to go into your GM settings and have GM create a custom password that only works with that app (in this case ISY). EDIT: Also, the whole reason I have ISY using GV instead of native texting is my T-mobile email to text has proven to work like crap. At 9:38 ISY sent me a text simultaneously to GV and to TMobile. The GV text arrived in less than 1 minute. The TMobile text took 45 minutes. Sometimes it comes right away, sometimes it takes hours. Anyone else using TMobile and having different results?

I use google voice which is set to copy all texts to my gmail. For this to work, you must use the same GM address in ISY as you use in GV. Send yourself a text, go to your email version of the text, copy the "from" address and use in your ISY as "to" address in ISY. The email address will look like this: yourphonenumber.yourphonenumber.randomlettersandnumbers@txt.voice.google.com The texts show up as coming from my phone number to my phone number, and the email version of it shows up as coming from my GM address. EDIT: Occurred to me that if you wanted ISY to have its own "from" address on texts, you could create a gmail address for ISY and get a google voice number for that email address. Send a text from yourself to your ISY GV number. Then, open that text in GM (the one for ISY) and copy the from address. Use that email address as the "to" address in ISY. The only trick is that GV is short on phone numbers. You might have to keep trying and trying before GV has an available phone number. Also, GV will cancel your phone number if you don't use it, I think that ISY sending email to texts will suffice to keep the number alive, but I can't be certain. I do know that sending texts from the GV webpage keeps a number alive since I have a GV number for just that and only that. It might be that you need to periodically send a text from the GV app or make a phone call from the app.

Since switching to IoP I had issues with email. They would work, or they wouldn't, randomly. I used the default mail server and then switched to gmail. My old 994 was on gmail as is another 994 I have currently running gmail. Also I have Blue Iris using gmail. All had the timeout set to 1000ms and all worked perfectly for many many years. In my frustrating trial and error trying to resolve this issue wit the new IoP, I tried increasing timeout to 2000ms. Low and behold, it started working better, but not perfect. Then 3000ms, now it seems to work 100% of the time. Anyway, it seems to me you shouldn't need a timeout of 3000ms unless something is wrong with the way IoP is handling mail. Anyone else having issues like this?

I checked my notifications and last time it worked was Aug 28. That could be when I switched to pg3 version. Edit. Yes, pg2 worked pg3 did not. I switched that day.

Any ideas? This is not a fresh restart, been running for weeks with a gazillion zone violations having occurred. Other info is correctly displayed. If I open an individual zone and violate/restore, it shows correctly. EDIT: Just to be clear, it is only on this screen that I'm not seeing zone violations. Last zone violated and last zone triggered. I tried a full reboot of polisy and it all the same.

So I have not read all the posts here so I might be repeating. I read the first few. What can happen with the query all is the following: If a program is set to run on the status of a device, and that device has an incorrect status in ISY because of a previously missed communication, then the query all will update that device's status to the correct status and in so doing, trigger any programs that included the device status in the "if" clause. So this issue will not happen every time there is a 3am query all. It only happens when the pre-query-all status is incorrect and the query updates it to the correct status. You should be able find the program that is being triggered by looking at your program summary page and finding programs that ran at ~3am. A potential way to avoid this issue is to use device "control" rather than "status" if possible. "control" will not trigger on a status change. Also, figuring out why the device status is wrong (or in other words why you have a com problem).

This is a bit confusing because of the way Insteon works. It is not a bad thing, it allows for great scene versatility, but with versatility comes confusion. First, remember the PLM/ISY is a member and controller for every scene. It is listed in the admin console tree as the root folder of each scene, but it is effectively no different than any other controller in the scene. To your specifics, you have to do all 3. 1) Scene on level when controlled by PLM. In other words, if ISY (or ud mobile) turns the scene on, the on level and ramp rate you set for each device is what will happen. 2) There is the local device on level. This is what THAT device does when you push the on paddle. You will need to set this for all devices in the scene. This does not need to be the same as when it is a responder to the scene. 3) There is the on level for the other devices in the scene SPECIFIC to which device turned it on. Basically this is the same thing as number 1 except instead of the plm being the source of the on command, it is what happens when any of the other devices in the scene initiate it. Because of how things are presented in the admin console, this is a bit different looking when you set it up, but it is the same thing as number 1. The way Insteon is set up, a scene is defined globally ONLY as the devices in the scene and whether they are controllers/responders, not how the devices respond. There is no global on level or ramp rate. If you have 3 devcies in a scene, you can have the 3 devices turn on differently depending on which of the 3 devices (plus PLM for a 4th version of the scene) you initiate it from. It is 1 group of devices that can behave 4 ways depending on which of the 4 controllers initiated it (3 devices or plm). In short, if you want a regular 3 way where you have 2 switches and ISY, all controlling the scene and you want the scene to behave the same regardless of which device you use to turn it on, then you have to set the on-level and ramp rate 3 times to the same values. Once for the scene as controlled from plm, once for the scene as controlled by each of the 2 devices, plus the local on level for each of the 2 devices. This allows for huge versatility, but it also means if you have a large scene with lots of controllers, you have a lot of settings to put in. It used to be that ISY had a "copy to all devices" button where you just clicked that button and it set all the devices levels in the scene to the same settings as the main PLM controlled scene. But they did away with that when they started adding non-insteon nodes since I guess it got too complicated.

Two "disable" options would do it. Easy enough to add it to a drop down menu, not sure how hard it would be to add it to the back end. "disable" "disable auto-triggering"

I'm pretty sure the answer is no, but I don't have CAO tags that do motion, only temp and door opening. However, CAO has a number of devices that can plug into a usb power supply. This is how I run my two wireless tags that are inside a walk-in freezer and fridge. But this requires that you physically go there to set it up.

Being able to disable a program (either from within the program or from another program) without terminating it would be nice. But since you can accomplish the same goal by just separating the trigger and execution into two programs, I really doubt UD would put such a wish on the short list of things to do.

Yes, and often times that ability to be interrupted is a useful tool. If you intend to have a wait or repeat always execute to completion, you need to have a separate programs for trigger and execution. If whatever you want Then Run then program 2 If blank Then disable program 1 do something wait do something wati etc. enable program 1 I use interruptible waits all the time as a hysteresis type mechanism. My dryer has a wrinkle protector that turns it on every few minutes. And using the notation option in an ISY program you save yourself confusion when a year or two or whatever later you can't remember. The notes included below are in the program, not added by me to this post. This sort of explanation in your programs is invaluable. Master Drier Copy - [ID 0163][Parent 00F7] If 'WebControl8 / Input8' Status is 0 Then Wait 5 minutes Enable Program 'Master Drier' Else - No Actions - (To add one, press 'Action') Input 8 is 1 when drier off. When air vent flapper opens input becomes 0. If the drier is on for 5 continuous minutes, master drier is enabled. At this point, the next time the flap closes (or in other words when it shuts off), it will send a notification and disable itself. It will not send a notification again until it the drier has run for 5 continuous minutes. Master Drier - [ID 00C6][Parent 00F7][Not Enabled][Run At Startup] If 'WebControl8 / Input8' Status is 1 Then Send Notification to 'lou text' content 'Master Dryer Done' Wait 1 second Disable Program 'Master Drier' Else - No Actions - (To add one, press 'Action')

@JaviI tried your new widget for turning switches on/off/slider. I applied it to a scene and instead of all the devices turning on/off together, they are staggered. I guess the widget just isn't meant for scenes?

If soldering is in your comfort zone, might just pull the relay and test it independently.

I did a package update from the AC. Now none of my PG2 or PG3 nodes will run. They all say "not running". If I try to run them, they just don't do anything, still "not running". This is every single node on both pg2 and 3. I tried multiple reboots of individual nodes, PG2, PG3, ISY, and the entire polisy. I put in a ticket, but I'm hoping someone can give me a quick fix. Here is an example log from one of the nodes. 2022-08-28 17:25:41,345 Command udi_interface.interface INFO interface:_handleInput: Received stop from Polyglot... Shutting Down. 2022-08-28 17:25:41,351 Command udi_interface.interface INFO interface:stop: Disconnecting from MQTT... localhost:1888 2022-08-28 17:25:41,352 Command udi_interface.interface INFO interface:_disconnect: MQTT Graceful disconnection. 2022-08-28 17:27:26,528 MainThread udi_interface INFO polylogger:set_basic_config: set_basic_config: enable=True level=30 2022-08-28 17:27:36,651 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.0.47 Starting... 2022-08-28 17:27:36,756 MainThread udi_interface.interface INFO interface:__init__: Initialization received from Polyglot V3 3.0.62 [ISY: 5.3.3, Slot: 7] 2022-08-28 17:27:36,759 MainThread udi_interface.interface INFO interface:__init__: Connect: Network Interface: {'addr': '192.168.1.9', 'netmask': '255.255.255.0', 'broadcast': '192.168.1.255'} 2022-08-28 17:27:36,762 Interface udi_interface.interface INFO interface:_startMqtt: Connecting to MQTT... localhost:1888 2022-08-28 17:27:36,863 MQTT udi_interface.interface INFO interface:_connect: MQTT Connected with result code 0 (Success) 2022-08-28 17:27:36,864 MQTT udi_interface.interface INFO interface:_connect: MQTT Subscribing to topic: udi/pg3/ns/clients/00:21:b9:02:38:63_7 - MID: 1 Result: 0 2022-08-28 17:27:36,872 MainThread udi_interface.interface WARNING interface:db_getNodeDrivers: controller not found in database. 2022-08-28 17:27:36,884 MainThread udi_interface.interface INFO interface:addNode: Adding node Push(controller) [None] 2022-08-28 17:27:36,886 MainThread udi_interface.interface INFO interface:setController: Using node "controller", driver "ST" for connection status. 2022-08-28 17:27:36,910 MQTT udi_interface.interface INFO interface:_subscribe: MQTT Subscribed Succesfully for Message ID: 1 - QoS: (0,) 2022-08-28 17:27:37,426 MQTT udi_interface.interface INFO interface:_message: Successfully set controller :: ST to 1 UOM 25 2022-08-28 17:27:37,715 Thread-1 udi_interface.interface INFO interface:addNode: Adding node hello(hellolo) [None] 2022-08-28 17:27:37,720 Thread-1 udi_interface.interface INFO interface:addNode: Adding node Office Alarming(officealarming) [None] 2022-08-28 17:27:37,725 Thread-1 udi_interface.interface INFO interface:addNode: Adding node Cadiz Alarming(cadizalarminng) [None] 2022-08-28 17:27:43,905 Thread-3 udi_interface INFO push-poly:start: Started Push Node Server 2022-08-28 17:27:43,907 Thread-3 udi_interface.interface INFO interface:updateProfile: Sending Install Profile command to Polyglot. 2022-08-28 17:27:51,594 MQTT udi_interface.interface INFO interface:_message: custom data response {'customparamsdoc': '<h3>Enter your Pushover credentials:</h3>\n\n<pre><code>Key Value\n\napi_key aslkti34cexample9faspff9bs\nuser_key 11lkj3an4kfother8s089exmpl90\n</code></pre>\n\n<h3>Enter things:</h3>\n\n<pre><code>Key Value\n\nFront Door you can leave this blank\nGarage Door\nEtc\n</code></pre>\n\n<p>The node address is derived from the first 12 characters and last 2 characters of the Key therefore each key needs to be unique.</p>\n\n<p>Be sure to save changes and restart the Node server.</p>\n'} 2022-08-28 17:27:51,745 MQTT udi_interface.interface INFO interface:_message: Successfully set key = customparamsdoc 2022-08-28 17:27:52,394 MQTT udi_interface.interface INFO interface:_message: Profile installation finished 2022-08-28 17:33:15,216 Command udi_interface.node INFO node:reportDrivers: Updating All Drivers to ISY for Push(controller) 2022-08-28 17:33:21,530 Command udi_interface.node INFO node:reportDrivers: Updating All Drivers to ISY for hello(hellolo) 2022-08-28 17:33:29,111 MQTT udi_interface.interface ERROR interface:_message: error No valid API calls provided 2022-08-28 17:33:29,112 MQTT udi_interface.interface ERROR interface:_message: Invalid command received in message from PG3: 'message' {"set":[]} 2022-08-28 17:33:41,586 MQTT udi_interface.interface INFO interface:_message: Successfully set controller :: ST to 1 UOM 25 2022-08-28 17:40:27,232 Command udi_interface.node INFO node:reportDrivers: Updating All Drivers to ISY for Push(controller) 2022-08-28 17:40:27,385 MQTT udi_interface.interface INFO interface:_message: Successfully set controller :: ST to 1 UOM 25 2022-08-28 17:40:27,829 Command udi_interface.node INFO node:reportDrivers: Updating All Drivers to ISY for hello(hellolo) 2022-08-28 17:40:27,908 MQTT udi_interface.interface ERROR interface:_message: error No valid API calls provided 2022-08-28 17:40:27,909 MQTT udi_interface.interface ERROR interface:_message: Invalid command received in message from PG3: 'message' {"set":[]} 2022-08-28 17:45:48,111 Command udi_interface.node INFO node:reportDrivers: Updating All Drivers to ISY for Office Alarming(officealarming) 2022-08-28 17:45:48,213 Command udi_interface.node INFO node:reportDrivers: Updating All Drivers to ISY for Cadiz Alarming(cadizalarminng) 2022-08-28 17:45:48,228 MQTT udi_interface.interface ERROR interface:_message: error No valid API calls provided 2022-08-28 17:45:48,229 MQTT udi_interface.interface ERROR interface:_message: Invalid command received in message from PG3: 'message' {"set":[]} 2022-08-28 17:45:48,268 MQTT udi_interface.interface ERROR interface:_message: error No valid API calls provided 2022-08-28 17:45:48,269 MQTT udi_interface.interface ERROR interface:_message: Invalid command received in message from PG3: 'message' {"set":[]} 2022-08-28 18:15:07,361 Command udi_interface.interface INFO interface:_handleInput: Received stop from Polyglot... Shutting Down. 2022-08-28 18:15:07,362 Command udi_interface.interface INFO interface:stop: Disconnecting from MQTT... localhost:1888 2022-08-28 18:15:07,363 Command udi_interface.interface INFO interface:_disconnect: MQTT Graceful disconnection.

I seem to have this working thanks to @Panda88 and @bpwwer The Tesla node server, with long poll set to 86400 and short poll set to 86399 (not sure if short poll is needed) lets the car sleep but you can send commands to it or query it when needed. The Emporia Vue node along with the device itself lets you monitor current real-time watt draw. There is a test version of the app that has this functional. Then I wrote a series of programs which seem to be doing the trick. I also have the programs in a folder which is linked to my phone geofence such that the programs only run when I am at the charging location in question. I don't want to have Tesla start and stop charging based on electricity usage at a location where the Tesla is not charging. It seems like a lot of programs, but I couldn't see a way to do it in fewer. I want the car to stop charging if power usage is above 14kw and then to resume when it drops below 9kw. I have the car set to charge at 3kw. I also don't want it to stop charging if there is just a quick spike from say a motor start, so I have a delay of 5 seconds, it checks again and then shuts down the car charger if it is still high wattage. Also, the Emporia Vue wattage is a state value and it updates every 2 seconds, meaning it will trigger an if clause every 2 seconds since the value always changes. So I didn't want the program to send a "start" or "stop" command repeatedly every 2 seconds once it has already started or stopped. Not sure if that would be a problem, but it just seems like a bad idea. Tesla - [ID 005C][Parent 0094] Folder Conditions for 'Tesla' FOLDER RULE If 'GeoFence Office / LouS22' Occupied is True Then Allow the programs in this folder to run. Tesla Charge Start - [ID 0062][Parent 005C][Not Enabled] If 'emporia VUE test' Killowatts < 9.0000 kW Then Run Program 'Tesla Charge Start 2' (Then Path) Else - No Actions - (To add one, press 'Action') Tesla Charge Start 2 - [ID 0066][Parent 005C] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Disable Program 'Tesla Charge Start' Set 'Raymond / EV Charging Info' Charging Control Start Enable Program 'Tesla Charge Stop' Else - No Actions - (To add one, press 'Action') Tesla Charge Stop - [ID 0060][Parent 005C] If 'emporia VUE test' Killowatts > 14.0000 kW Then Run Program 'Tesla Charge Stop 2' (Then Path) Else - No Actions - (To add one, press 'Action') Tesla Charge Stop 2 - [ID 0064][Parent 005C] If - No Conditions - (To add one, press 'Schedule' or 'Condition') Then Disable Program 'Tesla Charge Stop' Wait 5 seconds Run Program 'Tesla Charge Stop 3 always disabled' (If) Else - No Actions - (To add one, press 'Action') Tesla Charge Stop 3 always disabled - [ID 00D8][Parent 005C][Not Enabled] If 'emporia VUE test' Killowatts > 14.0000 kW Then Set 'Raymond / EV Charging Info' Charging Control Stop Enable Program 'Tesla Charge Start' Else Enable Program 'Tesla Charge Stop'

Already on the latest versions of IoP and PG. Not sure when I last updated the Polisy OS/libraries, probably a few months. I will go ahead and do that. However, Polisy did not crash nor did PG2/3. IoP was the only thing that crashed. Though, like I mentioned, it did not reconnect to the portal until I rebooted Polisy. Maybe I was impatient, but after waiting 5 or 10 minutes I figured it should have connected.

Thanks. Not sure I need support, I was just reporting an issue should UDI care to investigate. I didn't even know that UDI mobile was discontinued. Even though it is no longer listed in the google play store, it still transferred over when I bought my new phone a few weeks ago, so it was just there. I don't believe that the configuration step in setting up geo fencing has anything to do with UDI mobile. I forget now, but I believe the configuration step just sets up the node between portal and ISY. UDI mobile then updates the node whenever you cross in or out of a geofence. I believe you can use other apps and have them send to a unique url for entry/exit. But this brings up another point. If UDI Mobile is no longer to be used, then why is it still there on the portal?

UDI mobile is not an app to control ISY. It is a geofence app that integrates with ISY. It is the only app listed for geo-fencing. I suppose I could use some other geo-fence app and put in the url for in/out, but I assume since UDI Mobile is still the only one listed, that it is preferred. Also, the crash occurred during the "configuration", I do not believe that running the configuration tool has any connection to UDI Mobile. UDI Mobile, while being installed on my phone, had never been opened. It is a new phone that transferred automatically but I had yet to open it and it had no association yet with my ISY.

I was integrating UDI mobile/occupancy and this resulted in a full out crash of IoP. I had previously had my ISY linked to UDI mobile occupancy, but I guess that all got lost when I migrated to IoP. As I tried to add phones and locations, it said I need to configure. Upon opening the occupancy configuration tab and then asking it to "configure connection", IoP crashed. This is the first time I believe I have ever seen ISY crash. It self-rebooted, but did not sync with the portal upon reboot. The portal said "offline" even though I could log into the AC over my LAN. I proceeded then to reboot the entirety of Polisy from the PG2 GUI. Upon reboot this time, ISY did sync with the portal, but the node servers needed to be individually rebooted on both PG2 and 3 before they would sync with ISY, the nodes were all unpopulated prior. Rebooting Polisy seems to usually require the individual nodes to be rebooted, perhaps because they boot faster than ISY and then don't sync, I don't know. At this point I was able to configure occupancy. Anyway, something wasn't right.

This program stopped working. I think it started after I had some issues with PG3 nodes not connecting. I uninstalled and reinstalled blue iris node which fixed the failure to connect problem. But then this program stopped working: Driveway Entry Trigger - [ID 00AA][Parent 0172][Not Enabled] If 'Blue Iris / Front Entry' Triggered is True Then Run Program 'Driveway Entry' (Then Path) Else - No Actions - (To add one, press 'Action') On the AC, the camera "triggered" field would change from 0 to 1 when the camera triggered, but the program would not run. I changed the if to "is not true", saved it, then changed it back and saved it, and now it works. In short, not sure how this mapping works, but I thought if you put the same node in the same slot, it would be like it never left. It appears that there are some issues with that.