Andy P

Bob, I didn't notice this yesterday, but now all three days are showing the same forecast number for rain. Looks like forecast day 0 has rain, forecast day 1 has snow and that causes a parse error which also causes the same value for rain to show up in the other two forecast days and the snow value shows up as zero. Sorry, not high priority, but I'm sure you want this working right. Andy 2023-12-18 06:10:23,119 Thread-4 udi_interface INFO query:_query_forecast: Day = 0 - Forecast dt = 1702915200 2023-12-18 11:00:002023-12-18 06:10:23,119 Thread-4 udi_interface INFO query:_query_forecast: Day = 1 - Forecast dt = 1703005200 2023-12-19 12:00:00 2023-12-18 06:10:23,119 Thread-4 udi_interface WARNING query:_query_forecast: Failed to parse forecasted rain/snow data. 2023-12-18 06:10:23,119 Thread-4 udi_interface WARNING query:_query_forecast: 'rain' {'dt': 1702897822, 'sunrise': 1702901961, 'sunset': 1702935620, 'temp': 54.5, 'feels_like': 54.21, 'pressure': 986, 'humidity': 97, 'dew_point': 53.67, 'uvi': 0, 'clouds': 100, 'visibility': 4023, 'wind_speed': 16.11, 'wind_deg': 290, 'weather': [{'id': 501, 'main': 'Rain', 'description': 'moderate rain', 'icon': '10n'}], 'rain': {'1h': 3.16}}, 'daily': [{'dt': 1702915200, 'sunrise': 1702901961, 'sunset': 1702935620, 'moonrise': 1702918200, 'moonset': 1702959240, 'moon_phase': 0.21, 'temp': {'day': 47.37, 'min': 35.28, 'max': 57.52, 'night': 35.28, 'eve': 42.42, 'morn': 54.41}, 'feels_like': {'day': 39.97, 'night': 26.92, 'eve': 35.11, 'morn': 54.1}, 'pressure': 990, 'humidity': 83, 'dew_point': 42.44, 'wind_speed': 21.3, 'wind_deg': 313, 'wind_gust': 41.45, 'weather': [{'id': 502, 'main': 'Rain', 'description': 'heavy intensity rain', 'icon': '10d'}], 'clouds': 100, 'pop': 1, 'rain': 57.24, 'uvi': 0.74}, {'dt': 1703005200, 'sunrise': 1702988396, 'sunset': 1703022042, 'moonrise': 1703006040, 'moonset': 0, 'moon_phase': 0.25, 'temp': {'day': 36.9, 'min': 29.7, 'max': 37.58, 'night': 29.7, 'eve': 33.57, 'morn': 31.21}, 'feels_like': {'day': 27.66, 'night': 20.73, 'eve': 25, 'morn': 21.11}, 'pressure': 1017, 'humidity': 55, 'dew_point': 22.3, 'wind_speed': 16.13, 'wind_deg': 295, 'wind_gust': 29.19, 'weather': [{'id': 600, 'main': 'Snow', 'description': 'light snow', 'icon': '13d'}], 'clouds': 35, 'pop': 0.67, 'snow': 0.55, 'uvi': 1.4}, {'dt': 1703091600, 'sunrise': 1703074829, 'sunset': 1703108466, 'moonrise': 1703093880, 'moonset': 1703049900, 'moon_phase': 0.28, 'temp': {'day': 41.36, 'min': 28.45, 'max': 43.39, 'night': 33.98, 'eve': 35.6, 'morn': 28.67}, 'feels_like': {'day': 35.82, 'night': 28.6, 'eve': 30.43, 'morn': 21.51}, 'pressure': 1031, 'humidity': 43, 'dew_point': 20.53, 'wind_speed': 9.78, 'wind_deg': 310, 'wind_gust': 24.96, 'weather': [{'id': 800, 'main': 'Clear', 'description': 'clear sky', 'icon': '01d'}], 'clouds': 4, 'pop': 0, 'uvi': 1.62}, {'dt': 1703178000, 'sunrise': 1703161260, 'sunset': 1703194892, 'moonrise': 1703181780, 'moonset': 1703140560, 'moon_phase': 0.32, 'temp': {'day': 45.28, 'min': 32.72, 'max': 45.28, 'night': 34.52, 'eve': 36.81, 'morn': 32.72}, 'feels_like': {'day': 41.04, 'night': 29.61, 'eve': 32.07, 'morn': 26.64}, 'pressure': 1029, 'humidity': 46, 'dew_point': 25.54, 'wind_speed': 8.41, 'wind_deg': 351, 'wind_gust': 18.77, 'weather': [{'id': 800, 'main': 'Clear', 'description': 'clear sky', 'icon': '01d'}], 'clouds': 8, 'pop': 0, 'uvi': 1.54}, {'dt': 1703264400, 'sunrise': 1703247690, 'sunset': 1703281321, 'moonrise': 1703269740, 'moonset': 1703231160, 'moon_phase': 0.35, 'temp': {'day': 41.81, 'min': 31.06, 'max': 41.81, 'night': 35.89, 'eve': 35.98, 'morn': 31.06}, 'feels_like': {'day': 40.01, 'night': 32.43, 'eve': 35.98, 'morn': 26.2}, 'pressure': 1030, 'humidity': 42, 'dew_point': 20.52, 'wind_speed': 4.99, 'wind_deg': 5, 'wind_gust': 8.48, 'weather': [{'id': 803, 'main': 'Clouds', 'description': 'broken clouds', 'icon': '04d'}], 'clouds': 65, 'pop': 0, 'uvi': 2}, {'dt': 1703350800, 'sunrise': 1703334117, 'sunset': 1703367751, 'moonrise': 1703358000, 'moonset': 1703321880, 'moon_phase': 0.39, 'temp': {'day': 39.4, 'min': 33.84, 'max': 40.17, 'night': 40.17, 'eve': 39.56, 'morn': 34.29}, 'feels_like': {'day': 36.93, 'night': 37.33, 'eve': 37.2, 'morn': 31.77}, 'pressure': 1027, 'humidity': 84, 'dew_point': 35.15, 'wind_speed': 4.21, 'wind_deg': 303, 'wind_gust': 9.78, 'weather': [{'id': 804, 'main': 'Clouds', 'description': 'overcast clouds', 'icon': '04d'}], 'clouds': 100, 'pop': 0, 'uvi': 2}, {'dt': 1703437200, 'sunrise': 1703420542, 'sunset': 1703454183, 'moonrise': 1703446560, 'moonset': 1703412540, 'moon_phase': 0.42, 'temp': {'day': 46.33, 'min': 36.43, 'max': 46.33, 'night': 36.91, 'eve': 38.82, 'morn': 36.43}, 'feels_like': {'day': 42.93, 'night': 36.91, 'eve': 36.41, 'morn': 31.51}, 'pressure': 1028, 'humidity': 64, 'dew_point': 34.7, 'wind_speed': 8.03, 'wind_deg': 4, 'wind_gust': 18.72, 'weather': [{'id': 800, 'main': 'Clear', 'description': 'clear sky', 'icon': '01d'}], 'clouds': 4, 'pop': 0, 'uvi': 2}, {'dt': 1703523600, 'sunrise': 1703506966, 'sunset': 1703540618, 'moonrise': 1703535600, 'moonset': 1703503080, 'moon_phase': 0.46, 'temp': {'day': 45.27, 'min': 33.48, 'max': 45.27, 'night': 37.36, 'eve': 38.95, 'morn': 33.48}, 'feels_like': {'day': 43.18, 'night': 35.22, 'eve': 36.97, 'morn': 33.48}, 'pressure': 1027, 'humidity': 67, 'dew_point': 34.86, 'wind_speed': 4.27, 'wind_deg': 178, 'wind_gust': 5.26, 'weather': [{'id': 801, 'main': 'Clouds', 'description': 'few clouds', 'icon': '02d'}], 'clouds': 21, 'pop': 0, 'uvi': 2}],

Yes, the api definition shows that even when Imperial is specified, the rain and snow is still in mm One Call API: weather data for any geographical coordinate - OpenWeatherMap

Thanks, Bob - Got the new version and the number is no longer zero! However, there is that problem with the units of measure I mentioned. It is not UOM 105 apparently, it is UOM 106 that is coming back from the openweathermap API even though imperial is specified, for some reason the api returns mm/day. Or else I am in trouble with 31 inches of rain coming tomorrow!

Yes, there is an error in the debug log Here are the relevant pieces of the log: 'daily': [{'dt': 1702828800, 'sunrise': 1702815524, 'sunset': 1702849199, 'moonrise': 1702830120, 'moonset': 1702868400, 'moon_phase': 0.17, 'temp': {'day': 48.83, 'min': 42.01, 'max': 54.05, 'night': 54.05, 'eve': 52.65, 'morn': 43.57}, 'feels_like': {'day': 44.42, 'night': 53.76, 'eve': 52.07, 'morn': 39.13}, 'pressure': 1021, 'humidity': 98, 'dew_point': 48.25, 'wind_speed': 13.78, 'wind_deg': 76, 'wind_gust': 33.51, 'weather': [{'id': 502, 'main': 'Rain', 'description': 'heavy intensity rain', 'icon': '10d'}], 'clouds': 100, 'pop': 1, 'rain': 15.32, 'uvi': 0.43}, 2023-12-17 15:38:46,897 Thread-4 udi_interface INFO query:_query_forecast: Day = 0 - Forecast dt = 1702828800 2023-12-17 11:00:00 2023-12-17 15:38:46,897 Thread-4 udi_interface WARNING query:_query_forecast: Failed to parse forecasted rain/snow data. 2023-12-17 15:38:46,897 Thread-4 udi_interface WARNING query:_query_forecast: list indices must be integers or slices, not str 2023-12-17 15:38:46,916 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'CLIHUM', 'value': '98.0', 'uom': 22, 'text': None}]} 2023-12-17 15:38:46,916 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'BARPRES', 'value': '1021.0', 'uom': 117, 'text': None}]} 2023-12-17 15:38:46,917 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'DEWPT', 'value': '48.2', 'uom': 17, 'text': None}]} 2023-12-17 15:38:46,917 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV0', 'value': '54.0', 'uom': 17, 'text': None}]} 2023-12-17 15:38:46,917 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV1', 'value': '42.0', 'uom': 17, 'text': None}]} 2023-12-17 15:38:46,917 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV2', 'value': '44.4', 'uom': 17, 'text': None}]} 2023-12-17 15:38:46,917 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV14', 'value': '100.0', 'uom': 22, 'text': None}]} 2023-12-17 15:38:46,918 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV4', 'value': '13.8', 'uom': 48, 'text': None}]} 2023-12-17 15:38:46,918 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV19', 'value': '0.0', 'uom': 25, 'text': None}]} 2023-12-17 15:38:46,918 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV13', 'value': '502.0', 'uom': 25, 'text': None}]} 2023-12-17 15:38:46,918 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'UV', 'value': '0.4', 'uom': 71, 'text': None}]} 2023-12-17 15:38:46,919 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV8', 'value': '0.0', 'uom': 105, 'text': None}]} 2023-12-17 15:38:46,919 Thread-1 udi_interface.interface DEBUG interface:_send: PUBLISHING {'set': [{'address': 'forecast_0', 'driver': 'GV9', 'value': '0.0', 'uom': 105, 'text': None}]}

I have an EISY in the house and one in the barn. I wanted to be able to control some of the barn devices using the same web dashboard I use to control the house. I went through the forums and found lots of great information how to do this, so I am going to summarize it here to save others from having to hunt for it. 1. On the barn EISY, create a state variable that will represent the on/off status of the device you want to control remotely 2. On the house EISY, create a state variable that will mirror the value of the variable on the barn EISY. I used the same ID number to make things easier 3. On the barn EISY, create a network resource (Write Cupola) that sets the value of the house state variable from the value of the barn state variable using the API key for the house EISY from the portal (login to my.isy.io, select tool Information, select ISY Information, copy the URL to ISY info). Remember in my case they are both variable 13. The first 2/13 is the house variable that you are setting, the second 2.13 is the barn value you are using. The protocol name is GET but that is what you have to use to call the rest api even though you are putting the result to the other hub. Protocol Information: https GET Host: my.isy.io PORT: 443 Path: /isy/xxxxxxxxxxxhousethelongkeyfromtheportalxxx/rest/vars/set/2/13/${var.2.13} do not check Encode URI or Use SNI Under Details - Header - click on Add button and add Authorization which will pop up a window for you to put in your portal login information 4. Create a program on the barn EISY that runs when the device is switched on or off which then sets the value of the local variable and runs the network resource to copy it to the house. PushCupola - [ID 002D][Parent 002A] If 'Barn Cupola-On-Off' Status is On Then $sBarnCupola = 1 Resource 'Write Cupola' Else $sBarnCupola = 0 Resource 'Write Cupola' OK - now turn the device on the barn on and off a couple times and make sure the variable on the house hub switches between 0 and 1. To go back the other way, follow almost the identical process. You already have the variables set up, but you need a network resource on the house EISY to write back the barn for two way communication. Get the portal address for the barn the same was as you did for the house. 5. Create a network resource on the House EISY (Write Barn Cupola) that writes the value of the state variable to the barn. Remember I used the same variable id on both sides. If you have different ids, reverse them in this call from the one above. Protocol Information: https GET Host: my.isy.io PORT: 443 Path: /isy/xxxxxxxxxxxbarnthelongkeyfromtheportalxxx/rest/vars/set/2/13/${var.2.13} Under Details - Header - click on Add button and add Authorization which will pop up a window for you to put in your portal login information 6. Create a program on the house EISY that triggers the network resource when the value of the state variable changes ToBarnCupola - [ID 008E][Parent 0087] If $sBarnCupola is not -1 Then Resource 'Write Barn Cupola' Else - No Actions - (To add one, press 'Action') 7. Create a program on the barn EISY that reacts to a change in the state variable and switches the device on or off accordingly. SetCupola - [ID 0032][Parent 002A] If $sBarnCupola is 1 Then Set 'Barn Cupola-On-Off' On Else Set 'Barn Cupola-On-Off' Off Test this by changing the value of the variable in the house hub and see that it triggers the change in the barn. This is my dashboard that I use to trigger the remote devices - I am also mirroring the values of some Open/Close sensors. Hope this helps someone - as always, comments, corrections or suggestions are welcome! I should probably update the programs to set the init value whenever the local value is set. Andy

Seems that the rain accumulation is always showing zero? Should be 68.7 mm. Must be lost somewhere? The other values all seem ok. Here is the result of the direct api which uses the same values as the configuration of the node server. Not sure why rain is given in mm instead of inches but it is the same on the web page (I added that picture later so the values don't match exactly): api.openweathermap.org/data/2.5/onecall?lat=39.xxx&lon=-75,xxxx&appid=xxxxxxxxxxxxxxxxxxxxxxxx&units=imperial "dt": 1702915200, "sunrise": 1702901961, "sunset": 1702935620, "moonrise": 1702918200, "moonset": 1702959240, "moon_phase": 0.21, "temp": { "day": 48.61, "min": 36.73, "max": 56.57, "night": 36.73, "eve": 43.52, "morn": 55.53 }, "feels_like": { "day": 41.38, "night": 28.69, "eve": 36.77, "morn": 55.38 }, "pressure": 990, "humidity": 85, "dew_point": 44.24, "wind_speed": 22.21, "wind_deg": 297, "wind_gust": 36.62, "weather": [ { "id": 502, "main": "Rain", "description": "heavy intensity rain", "icon": "10d" } ], "clouds": 100, "pop": 1, "rain": 68.7, "uvi": 0.21

Both eisy and firmware are at the same level. They haven't gone blank in a while so I have been waiting to do the restore device sinceI wanted to determine if there is some pattern. Thanks

I wanted to check this and found a downlevel Python so I did the reinstall all plugins - this is the actual log entry referenced by @DennisC after the reinstall: UDI Python Interface for Polyglot version 3 3.2.6 Starting... Thanks

Since the demise of the MyQ nodeserver due to being locked out of the API, I installed new Triggerlinc 2843-222 Open/Close Sensors (V43) on my garage doors. I already have a bunch of them on other doors. Install went fine, there are plenty of other insteon devices in the garage so no problem with communication. What I don't understand is why the status in the admin console goes from On or Off to blank after a number of hours. (EISY v5.7.1) In the latest case, the door opened at 11:43 am, closed at 11:44am and i received a heartbeat at 6:05pm - I see all that in the log. The admin console showed the door as closed (off) most of the day, but in the evening I noticed the status was blank. In fact, three of my open/close sensors then had gone blank. There is no indication in the log of why they would go blank. A bunch of the other open/close sensors still show Off so it doesn't happen to all of them. SO they have fresh batteries and good communication and I am receiving a heatbeat, but the status disappears. Any clue what is going on and how to avoid the status going blank? Just to add - I did not restart the EISY or IOX during this time, I know there is a blank status until the first event gets reported. Thanks, Andy

To save someone a bit of time getting the UnifiPresence node server working for the first time, this is what I discovered when setting it up - some of this is probably obvious but I did waste a lot of time figuring it all out. 1 unifi_host -> UDM / Cloud Key - IP - this one is easy - go to unifi.ui.com or your local controller web page and look under UniFi Devices for the controller - in my case a cloudkey - and copy the ip address - like 192.168.1.7 for example 2 unifi_port -> UDM / Cloud Key - Port - well I wasn't sure if it should be 22, 443 or 8443 and tried them all. Turned out 443 was correct 3 unifi_userid -> UDM / Cloud Key - UserID - i had three choices for this, maybe it would be ubnt, or admin, or a custom id I had set up. Turned out to be the custom id 4 unifi_password -> UDM / Cloud Key - Password - the password that goes with the userid above 5 unifi_siteid -> UDM / Cloud Key - Site (default) - if you have a simple setup, it is just the word default, no parenthesis or anything 6 mac_device -> Provide a comma delimited list of mac address of device to detect presence on the network. (ff:ff:ff:ff:ff:ff,ff:ff:ff:ff:ff:ff) - do NOT put them in parenthesis, no spaces, just a comma in between. You can easily find the mac address of devices in the Unifi console under Client Devices - Overview If you get the first 2 right configuration parameters, you will get just one node with the controller called UnifiCtrl. It will show up with either Status - True or False and will have the address n00x_controller where x is the slot you installed the node server in If you get the rest correct, you will get additional nodes for each mac address you included the configuration. The node name will default to the mac address, but you can freely rename it to something like myphone without any problem. The underlying node name will be something like n00x_xxxxxxxxxxxx based on the slot and macid respectively. This is standard node server behavior. If you look in the admin console device summary table, the controller node with show true or false, but the mac nodes will show blank. That is because the status is not being put into the Status field for the individual devices, it is being put in to the GV1 field. You have to go to the detail of the node and it will show up as Online - True or False. To use this to trigger a program, use a condition that tests Status - Online = True or False for the mac devices or use Status - Status - True or False for the controller. If you are having trouble, use the Polyglot console and turn on Debug level logging to get a better idea of what is failing. Good luck! Andy

Excellent! After updating the node server and recycling IOX I found the icon url in GV21 - thanks!

Bob, do you get the icon filename data back from OpenWeatherMap that you could pass as a property for the controller and forecast nodes? Then I could download those 18 icons and use them in my display. Otherwise I have to build a table of weather condition value to icon name. Weather Conditions - OpenWeatherMap

oh, now I see the difference. The ones that were formatted prior to the restart were all using standard UOM (units of measure) and precision to generate the formatted text. But those two have UOM=25. ISY Developers:API:V5:Appendix:Units of Measure - Universal Devices, Inc. Wiki (universal-devices.com)

Interesting. Two values changed to include the formatted text after the restart and now the name value is filled in for all of them. <property id="GV13" value="701" formatted="mist" uom="25" name="Climate Conditions"/> <property id="ST" value="1" formatted="Connected" uom="25" name="NodeServer Online"/> Thanks!

Thanks, I understand number two and that needs to be done by UDI. Regarding the first question, I am getting text formatted values for all the other variables, just not GV13 - but I guess I will go restart IOX and see if that changes. <property id="BARPRES" value="1004" formatted="1004 mb" uom="117" name=""/> <property id="CLIHUM" value="96" formatted="96%" uom="22" name=""/> <property id="CLITEMP" value="5167" formatted="51.67°F" uom="17" prec="2" name=""/> <property id="DEWPT" value="5058" formatted="50.58°F" uom="17" prec="2" name=""/> <property id="DISTANC" value="1" formatted="1 Miles" uom="116" name=""/> <property id="GV13" value="701" formatted="701" uom="25" name=""/> <property id="GV14" value="100" formatted="100%" uom="22" name=""/> <property id="GV18" value="0" formatted="0%" uom="22" name=""/> <property id="GV2" value="5106" formatted="51.06°F" uom="17" prec="2" name=""/> <property id="GV4" value="461" formatted="4.61 mph" uom="48" prec="2" name=""/> <property id="GV5" value="599" formatted="5.99 mph" uom="48" prec="2" name=""/> <property id="GV6" value="0" formatted="0 inches/hour" uom="24" name=""/> <property id="GV7" value="0" formatted="0 inches/hour" uom="24" name=""/> <property id="ST" value="1" formatted="1" uom="25" name=""/> <property id="UV" value="12" formatted="0.12 UV Index" uom="71" prec="2" name=""/> <property id="WINDDIR" value="90" formatted="East" uom="76" name=""/>

Hi Bob, thanks for providing/supporting the openweathermap nodeserver. I got it up and running pretty fast once I subscribed to the service and put in the config. Question about the formatted data being provided for 'weather conditions'. In the admin console, you are converting the numeric value ''804" to "Overcast clouds" which is very useful. In the rest api, when I request the node data, a lot of the values do get different values between the value and the formatted value (like 599 becomes 5.99 MPH) but the weather conditions does not. <property id="GV13" value="804" formatted="804" uom="25" name=""/> Is there any chance you could put the same formatted value from the admin console into the formatted value of GV13 or perhaps create a new property id="CONDITIONS" with the formatted value? Otherwise I will have to do the translation in javascript. Appreciate your consideration. Second question - since I don't need the API polling every 10 minutes all night, is there a way either to provide a sleep time period or to turn polling on and off via a program for when I don't need it to update? I know that first 1000 calls to the api are free, but don't see any reason to poll if I am not needing the data to be updated. Thanks, Andy

I would approach it by isolating the factors. First, remove the load from that dimmer and see if it acts the same. I have seen strange behavior when the load is too little like a single led bulb. Then, if it is still acting flaky, remove the other switch from the circuit by disconnecting the black and white wires from that switch. Finally, swap the load between the two switches and see if the problem moves.

I had a bunch that fired at the same time - like sunset - and would occasionally get devices that did not turn on or off as part of the mix, so I staggered the program triggers by a minute or so each and those problems mostly went away. You will also see advice in this forum from time to time to add 'delays' in programs when there are a large string of devices turning on and off. I have also used that technique to improve the reliability of some programs. Combining those two thoughts, if you still want to trigger the events at the same time, you could put various delays at the start of those events to achieve the stagger. I suppose all of this might just be making up for less than ideal communication or interference in the home, but some of those intermittent problems are really hard to find.

It must be the starting amps that are requiring 40A because most well pumps run less than 20 I believe. I also have a variable speed pressure maintaining setup using a Franklin Electric subdrive controller and a 2hp submerged well pump 300' deep. According to the tables, 2hp 240 VAC draws about 10amps but of course the starting current is higher.

I noticed this morning that 5.7.1 is now up to _05 Release notes for: 5.7.1_05 - 11/29/2023 - Crash while initializing PLM (older versions) Release notes for: 5.7.1_03 - 11/27/2023 - Zooz dongle issue - Initial db Release notes for: 5.7.1_02 - 11/15/2023 Fixes - Crash during restart - Crash during usubscribe - Z-Wave change from bridge to static <br/>

I was pondering the same question when building a new house - then I realized I have a well! And that means I just have to cut power to the well. So, I installed one of these GE Enbrighten 240 volt - 40 amp z-wave switches and trigger it with a leak sensor. (The well pump only uses a 20 amp circuit for those electricians wondering about the bx cable).

Just wanted to share a couple updates. This includes how I am showing the 24 hour cycle of lights on and off and when there is motion. The circle around the device with gray and yellow for lights on and off. Red circle with spokes for motion. The green dot is the current time. Also showing when certain scheduled actions will occur and how long until that happens. The gray pie is a 24 hour clock and when it is within one hour it switches to the green pie. There is also a gant style timeline of the log and a pop up when you hover the mouse to get the controls and access to the log entries for that device. I am doing all this with simple javascript using the response from the rest api. Love to have any suggestions or ideas from the community! Andy

Steve, the first thing I would suggest is don't panic. The insteon stuff is solid and with a little time invested you can get it working the way you want. If you don't want to invest the time, you could of course just replace everything with dumb switches and be done. If you have a dimmer that does nothing, it means that there is another dimmer that is actually controlling the load. If you look at the instructions for those dimmers, you just have to reset them both then link them together. This works even without any hub. If you need more help with how to do that, plenty of people on this forum can help you if you just describe where you are at with each device. I suggest you start with a single pair of devices that aren't working. Factory reset the one that controls the light. Factory reset the one that is supposed to be linked to it, and then use the instructions for how to link those switches together. Get that working and just repeat it for the rest of the house. If you want more control and automation, invest in a hub. For this group, the EISY is the preferred option. but to be clear, you don't need a hub to get your stuff working again. Best, Andy

This absolutely should work and certainly does for me. If Time is Sunrise Then ... So 1. Check - did you click on Save Changes at the bottom of the programs tab? 2. At the top of the admin console, does it show the right time for Sunrise and Sunset? 3. In the programs summary page tab does it show times for Next Scheduled Run and 'On' in the enabled column?

I am using the result of the /rest/log response to create a visual timeline of events. I really only need about the last 800 log entries, but the rest command returns the entire log (so 10's of thousands of records). I can clear the log, but then I lose the most recent entries as well and I cannot see a way to clear the log prior to a certain date. The program works fine, but it feels like I am making it work harder than it needs to. So specifically asking: 1: can /rest/log be called in a way that limits the response to the last n entries? 2. can the current log reset be done but preserve the last n days or n entries? I attached a view of the timeline generated by javascript/html/css from the log. EISY v5.7.0 Thanks, Andy