Andy P

Is that $260 for the EISY and $126 for the zwave dongle (which isn't needed for insteon)? I think I have around 100 insteon devices which cost anywhere from $30 to $79, so lets say $50 each meaning $5000 invested. Doesn't feel overpriced to have a hub for $260. I have seen some others make the jump to HA and RPi. I think the user interface is definitely a lot more modern than the Admin Console, but they also spend a lot more time trying to make everything work. For me the biggest advantage of going to the EISY over the ISY is the additional power to run all the node servers. I actually like the EISY box enough that I bought a couple of the MELE quieter3c boxes to replace windows pcs in my house. Good luck whichever way you choose to go. Andy

Insteon has not yet responded to my ticket - I sent them a reminder. Meanwhile, I ordered a couple more keypads so will report back what I find with the others.

Yes, @paulbates, that is where I expected to find it, but no option under any of the drop downs or the buttons at the bottom

I opened a ticket with Insteon - let's see how/if they respond.

I take a different approach. I have three programs - two for the conditions at night before and after midnight (Breezeway Motion Off Dim and Off Off) and one for the conditions during the day (Breezeway Motion Daytime). Then I use another program which runs at the crossover time and turns on the outside lights to also enable one program and disable the others. Then I use the program that runs at midnight and one that runs in the morning to change which of those is enabled and disabled. I just found this easier than trying to do it all in one program. Sunset Actions - [ID 0003][Parent 000D] If Time is Sunset Then Set 'Garage Sconces (SC)' On 20% Set 'Breezeway' On 15% Set 'Front Sconces (SC Front Dr)' On 20% Set 'Rear Sconces (Screen Porch SC' On 20% Set 'Front Balcony Sconces' On 20% Set 'Rear Balcony Sconces' On 20% Set 'Foyer Sconces' On Set 'Slat Wall' On 12% Wait 5 seconds Resource 'Notify Sunset' Enable Program 'PreDawn Sconces' Enable Program 'PreDawn Slatwall' Enable Program 'Breezeway Motion' Enable Program 'Breezeway Motion Off Dim' Disable Program 'Breezeway Motion Daytime' Else - No Actions - (To add one, press 'Action')

I just installed an i3 keypad and was surprised when the load was controlled by the bottom button not the top button. According to the manual, the factory default is supposed to be the top button. Did anyone else have this experience? I went looking for how to change which keypad button controls the load using the EISY admin console but did not find the option. Anyone know how to do this? So, I factory reset the keypad by pulling out the airgap switch, then pushing it in until the beep stopped. After the reset, the top button now controls the load, but I am left wondering. I also did a restore device from the AC to add back the links and all is working fine. Andy

That is pretty close to what I do, except in the THEN clause, I set a state variable $sBarnLightOn to 1 if any light is on and 0 otherwise. Then I use a second program that triggers off the state variable. The main reason I do this is in case I want to have multiple programs that take advantage of the lights being on or off flag - for example, a program that sends a notification if the basement lights are left on past 10pm (and doesn't just shut them off in case I am in there). I do the same thing with a state variable called '$sAnyZoneFaulted' which is a whole bunch of if statements on the node server nodes. btw, in another case, I am not turning the light on and off, I am changing the color of the LED on the zen32 - this one just turns the lights on and off but you can use the other advanced settings to change the color. Dormer light status - [ID 0020][Parent 0007] If 'Barn Dormer' Status is 100% Then Wait 1 second Set 'Shop Loft-Binary' Set Configuration Parameter 3 = 3 Wait 1 second Set 'Shop Loft-Binary' Set Configuration Parameter 5 = 2 Else Wait 1 second Set 'Shop Loft-Binary' Set Configuration Parameter 5 = 3 Wait 1 second Set 'Shop Loft-Binary' Set Configuration Parameter 3 = 2 (at the time I am posting this, you can find the configuration parameters for the zen32 here: ZEN32 Scene Controller Advanced Settings - Zooz Support Center (getzooz.com) )

Bob, it does look like you nailed it! Thanks! Andy

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.