Jump to content

madcodger

Members
  • Posts

    541
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

madcodger's Achievements

Advanced

Advanced (5/6)

100

Reputation

  1. Understood, and thank you. If you should ever wish to try this and need a "lab rat", please feel free to let me know. I wonder if user-selectable "tradeoffs" of captured values, or frequency of updates, might mitigate this somewhat? For example, I never really use barometric pressure, and 15-minute increments of outside temperature updates would be plenty for my personal needs, if it allowed me to monitor indoor temp and humidity, or gain better access to an additional parameter, such as daily rainfall. Anyway, I am grateful for the access I have, and appreciate your efforts. Thank You!
  2. Hi Bob @bpwwer, I wonder if it might be possible to "expose" each of the various "sub-devices" (w.g., daily rainfall, hourly rainfall under Precipitation, inside temperature under Temperatures, indoor humidity under Humidity) so that they could be "picked up"/read by some of the mobile apps that are on offer? I can see each of these just fine in the admin console, but if there is more than one "sub-device" in each heading, I see only one of these sub-devices when I am using Orchestrated Mobilinc (OML). In my case, for "devices" that have multiple "sub-devices", I see only Temperature (which is the outdoor temp), Humidity (the outdoor humidity), Wind Speed (current wind speed, but not gust speed, wind direction, or average wind speed), and Rain Rate (under Precipitation). Barometric pressure shows only the current pressure, of course, and I see that. I realize this is likely a limitation of Mobilinc, but if there were a tweak possible from the node server end that would address this I thought I would bring up the idea, to see if something might be possible. Wes isn't making changes or updates to OML now, and I don't think his more recent product, Mobilinc X, addresses this, either. So, absolutely no expectation of you, of course (you've already done us all a huge favor by developing this excellent nodeserver) but I didn't know exactly where else to turn, so thought I'd bring it up. Thanks for all you've done, and do. If you have any ideas or suggestions, I'm all ears. Thanks!
  3. I have no idea whether it's related or not, but report this on the odd chance that it's related and knowing it might help. Separate from the nodeserver (not connected to it at all), at least one temp sensor that reports to the ISY - the Homeseer FS-100 - oddly reports its temps only in Celsius, despite showing as Fahrenheit with other automation controllers (e.g., Homeseer itself). No one seems to know why, each company blames the other, and I've just learned to live with it. It might not be related to this problem at all, of course, but if it is, you now perhaps have another data point.
  4. @RRoyceusAnother suggestion is to start a new thread, in which you note your specific z-wave issues (with a somewhat descriptive title). I think many people stop following these "release version" threads once their system is stable on that release, and thst likely applies here. As noted above, it does help to describe the problem (actual symptoms) you're having. Without looking at me system (typing this from an iPad, so can't use admin console), I'd guess your z-wave firmware is fine. The ISY does not have the best z-wave radio/antenna configuration, though, so I've found that it needs some help in the form of repeaters, setting some things up right at the device, performing network heals, etc. It will "get there" and remain stable, but it can take a day or two to get there.
  5. Your program actually says ">=0.3". Have you tried ">0.2"? My theory is that because the VP2 measures to 0.01", you might have a rounding problem. Absent that being the issue, it may be that the rounding of either the ISY is not sufficiently granular for this, or perhaps the rounding in Bob's nodeserver. The fact that 0.5" lappears to be the "cutoff" seems to suggest that. Another approach might be to try setting up a state variable, in which ">0.2 inches" sets the variable to 1 (on) while "<=0.2" turns it off (sets it to 0). It would be interesting to see if things are processed differently for variables as the trigger. Just a couple of thoughts to explore on the path ro a solution.
×
×
  • Create New...