bpwwer

@tmorse305 I looked over the code and it looks like that happens when the plug-in starts? When the login to the Emporia servers fails, it throws the error but then continues to try and discover devices, which also fails, throwing the second error. At that point the plug-in basically stops. I can make some changes to have the login attempt loop until it succeeds, that might help some. But I also don't see anything in the library code to re-login if queries fail so I think that's going to cause similar problems where the plug-in may just fail to query until it's restarted. I can add some checks to try and detect query failures, but that's one of those things that hard to test without there being actual failures.

I don't know. He hasn't made any changes to it since I ported it to PG3.

I've pushed out a new version, but I can't update the store entry. However, you should be able to go to the store and install/re-install it and it will install the new version (3.0.1).

From what I can tell, the plug-in never actually updated the temperature values. It would get the current values when the plug-in starts but then never updates them. It did get updates for the pucks and vents (but not the rooms) and would update some of the other values like rssi from the update. I think I have it mostly working now but since I don't own the plug-in, I'll have to see what i can do to get it updated in the store.

@DHemrick02 I'm taking a look at it and I don't really see anything that looks wrong. However, it does look like the code is designed to only trigger a temperature change on 1 degree Celsius changes. This may account for some/all of the issues you're seeing. The temperatures are in C and get converted to F in the plug-in. So anything between 17.0 to 17.99 C will get converted to 62.6F. If it was doing the conversion properly, you'd see values between 62.6 and 64.4F Also, it's not yet clear to me how often the pucks (and vents, etc.) report updated values to the server. Some info I found on-line indicates that the puck display will only update if the temperature changes is greater than 1.1C (2F) and it does this to reduce internet traffic. How updating the display is related to internet traffic is unclear. Possibly that really means that it doesn't send updates to the server. If that's the case, then you'll never be able to get good real-time data from these things. https://support.flair.co/hc/en-us/articles/360049596711-Why-is-the-temperature-on-the-Puck-different-than-the-Flair-app I'm going to send you PM with some additional information.

Chris also owns 25957. Anything z-wave related has likely been assigned to Chris. I don't know why he hasn't responded to any of them but hopefully there'll be an update after Monday.

PG3 had the ability to read a PG2 backup file and attempt to migrate PG2 plug-ins to PG3, but it would only work in a few cases. PG3x only has the ability to migrate plug-ins from PG3. PG2 was EOL'd before PG3x was available so no effort was made to migrate from a system that had been EOL'd for a while.

I'm not sure I should reply to this or not, but I'll risk it. I'm not representing UDI and I'm also not very familiar with z-wave devices in general. However, if I understand your ticket, I think the issue is really on the HomeAssistant side of things. The eisy has the concepts of control and status. Those are separate things. Control is an action (I.E. pressing a button) while status is a state (I.E. on/off). From your ticket it sounds like eisy is correctly identifying those. When you press the button there is a control action of ON. You should be able to create an eisy program something like if control scene buttn x sends on do something. This program would run anytime you pressed the button. The eisy also changes the status/state to ON. No matter how many times you press the button , that status/state does not change so nothing that is triggered on that state change will happen. This includes HomeAssistant, which appears to only be triggering on a status/state change. If HomeAssistant would/could also respond to the control action, it would likely work as you want. My personal opinion is that scene buttons like that should not have a status/state because it's confusing and there's no way to handle well. If anything, buttons like that should have a "pressed" and "released" states as that more closes matches what's really happening with things like scene buttons (or really buttons in general). Status/state should be used for devices that actually have a state, like a light or relay. I can't help at all with your second ticket. Both seem to assigned to the right person but I don't know why he hasn't responded to the tickets.

That's going to depend on where each service is getting the data for your location. Chances are pretty good that neither will be all that good as they tend to get data from airports. Unless you live next to an airport that is providing data it will probably not reflect what is happen at your location. However, none of the weather service data provides are very transparent about where the data comes from so you may get lucky and one of them is getting data from a weather station close by. If you really want accurate data for your location, your best bet is to get a personal weather station and use that data.

As others have mentioned, the short answer is yes. There are a number of plug-ins that make use of USB->RS232 interfaces to control devices; Russound RNET and the two USB relay modules are the ones I'm familiar with. However, those plug-in are all written for the specific command set of the device they are trying to control. There isn't a generic USB<->RS232 plug-in that you could use to control HomeWorks. I do have plug-ins for Lutron Caseta (and RA3) and RA2. I can't imagine that the HomeWorks command set is all that different. It may be possible to use the LutronRA2 plug-in with a USB to serial adapter connected to a HomeWorks controller. It would be an interesting experiment anyways.

Thanks for verifying!

Pushed version 1.0.1 with the fix.

Of course the data being sent would be different from what they document. Why would I expect their documents to be right [he said with much sarcasm]. It's an easy fix, I'll have it done shortly.

Next release - version 2.0.13 has been published to the plug-in store.

Nevermind, the raw data was in the attached lot in the first post. It looks like they added aqi data (named aqi_pm25), which matched the PM 2.5 sensor in the plug-in's parser. Should be fixed in the next release.

Ok, I see the problem. More issues with the data from Ambient. Looks like you have to air quality sensors. In all other cases, Ambient seems to append a number to the sensor field name to differentiate between multiple sensors of that type. They may be doing that for air quality sensors as well, but it's not documented that way in the API docs. I guess I really need to see the raw data you're getting for the station to see if this is something I can program around. When the plug-in is set to debug level logging, it should be dumping the raw data to the log file. The reason it matters is because the IoX/ISY needs each piece of data needs to map to a list of pre-defined, unique data identifiers. For air quality , the IoX/ISY supports only one PM 2.5 data value and Ambient is listing two in the data. Since the plug-in is parsing the data and dynamically creating the mapping to IoX/ISY types, it ends up creating two PM 2.5 node values with the same type. Then the Admin Console flags that as an error.

After clicking the Load Profile button, check the PG3 log. Are there any errors? Your description sounds like the admin console isn't getting all the profile files, but you say the mobile app is working fine so it's able to get those same files. That implies that the problem is with the admin console. If you can, enable the java console for the admin console (how you do this depends on the computer you're running the admin console on) and restart the admin console. The java console log will show errors it it's having issues with the profile files.

That sounds like the Admin Console didn't get the node definition for that node. Try the "Load Profile" button from the PG3 Ambient plugin details page. Then restart the Admin Console.

I can't help with the admin console showing different values than the mobile app or PG3. Once the plug-in feeds the data to PG3, it's no longer in control of where it goes or what happens to it. As to why you are only seeing a few values in the three nodes, what are you expecting to see? The plug-in parses the data from Ambient into the different sensors. Typically they name the data fields with different suffixes for each sensor. That's why there are three nodes, it seeing data fields with no suffix (main), data fields with '_in' suffix for the indoor sensor, and '_4' for sensor #4. Because of how plug-ins work, it can only support data fields that it knows about. So any data fields that the plug-in doesn't have a known mapping for, it ignores. With the plug-in log level set to debug, the log will show the raw data received from Ambient and which fields are being ignored.

Your station name has a character that is illegal to use in a node name. That's why it keeps failing. I believe node names are restricted to just alpha/numeric characters and maybe _ and - so PATTON&DNSVIEW fails because of the '&'.

You'll get more info about what is failing if you switch the log level of the plug-in to debug. It will then log what is being returned by the query. The error message indicates that what is being returned isn't in the format expected so it could be an error message. The request being made is: https://api.weatherlink.com/v1/NoaaExt.json?user=<Device ID>&pass=<Password>&apiToken=<API Token> You can try that in the browser using your parameters and see what it returns. There is a newer API available and a newer plugin that uses it. It's possible that this version of the API has been discontinued and no longer works. If that's the case I'll have to remove the plug-in. The version that uses the new API version is in the non-production store and named Davis_V2

I just publish version 2.0.11 which should clear the alerts once they are no longer active.

As near as I can tell something changed in the response from NOAA. The plug-in is looking for "There are no active watches, warnings or advisories" but that doesn't seem to exist anymore. Instead, the response is pretty much empty. I'll need to re-work the plug-in to detect that the response is empty instead of looking for that string.

Mostly, plug-in come to be because someone has a need for it. In many cases, the person with the need also has enough of a programming background (or is willing to take the time to learn enough) to create it themselves and then make it available for others. There are also cases where an existing plug-in developer will create a plug-in for others. In some cases this may be a work-for-hire (I.E someone pays them $500 to create the plug-in) or they may think it will be popular enough to make it worth their while. For this to work, there are typically some requirements: The developer needs access to the hardware that the plug-in is for. This may be that someone sends them hardware or someone with the hardware is willing to do a lot of testing for the developer. The developer needs access to documentation on how to talk to the hardware. Apparently, u-tec just released an API for local control of the locks and more, like just released in the past month or so. https://developer.uhomelabs.com/hc/en-us/articles/39731959004057-What-is-U-home-OpenAPI Looks like there might be enough there to develop a plug-in for it.

The plug-in sends the data to PG3x. If the data is showing up in PG3x and is updating, then the plug-in is working correctly and the problem lies elsewhere. If the data is not updating in PG3x, then it is most likely that the WeatherFlow hub is no longer sending out updates or something changed on your network such that the data being sent by the WeatherFlow hub is being blocked. This assumes you are configured to get data from the hub and not from the WeatherFlow servers. If you're configured to get the data from the WeatherFlow servers, then it's likely the requests to the server are failing or the server is failing to respond with any data. In all cases, the plug-in log file (once switched to debug level) what the plug-in is doing and if it is encountering any issues.