-
Posts
3149 -
Joined
-
Last visited
About bpwwer
- Currently Using Personal Messenger
Profile Information
-
Location
California, somewhere north
-
Occupation
Software Engineer
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
bpwwer's Achievements
-
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 '&'.
-
No Data retrieved from DavisWeather IP interface
bpwwer replied to Breezyken's topic in DavisWeather
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.
-
Most RS232 devices can be supported on a eisy via a rs232<>ethernet bridge device assuming someone creates the plug-in for that. That's how the Russound RNET plug-in works. There are a number of security panels supported via plug-ins, but not the HAI OmniPro. Not sure why no one has created a plug-in for that. Likely it would have to be someone capable of creating plug-ins and who has an OmniPro that they want to keep using. I suspect that there's just not enough demand to make it worth while for any of the existing developers. I created a plug-in for the DSC IT-100 interface (the RS232 interface for PC1616-1864 panels). This plug-in is in the non-production store as I don't think there's enough demand to even make it a production plug-in. The Envisilink plug-in and solution is much better. I interfaced to the IT-100 using Global Tach RS232 to Ethernet interface. I would think that an OmniPro plug-in would be similar.