I've developed and tested for several weeks a new parent driver and supporting child drivers for the Embedded Data Systems HA7Net - Ethernet 1-Wire Host Adapter product.
Although this device is rather old, 1-Wire sensors are pretty inexpensive and reliable. For example, I've attached a series of DS18S20 temperature sensors to copper pipes to monitor water temperature of our ground source heat pump supply and return lines and the intake and supply lines of our domestic hot water tanks.
Since the HA7Net provides a web interface and documented schema of web requests and responses, it can be used directly from the HE without the need for an intermediate application.
Embedded Data Systems' OW-Server device is newer replacement for the HA7Net, but it is not currently supported by these drivers.
People developing parent-child drivers might also find it useful to review this code as an example.
I still have a handful of DS18S20 1 wire sensors and cables from my old HomeVision Pro days as that had a direct interface for them. They were very reliable and accurate with that.
I wasn't even aware of the HA7Net system until your post, but it sounds interesting so I've just bagged a used one from Ebay to give it a try. I am not 100% happy with any of the wireless temperature measuring sensors I've had so far so maybe this will be a good solution.
I have this reliable unit hooked to about 30 wired 1-wire sensors and it never failed one time in years. Other advantages`: wired non-powered temperature sensors to put in water, soil, along pipes, in wells, outside, etc.
Since one of my overall goals for HA is to minimize the need for and dependence on apps running on our home server, I like the direct Hubitat to HA7Net integration in which an intermediary application is not needed. (The newer OW-Server device has similar capabilities and could also be integrated directly with HE).
Via the HA7Net web UI can you get the sensor ID of one of these sensors and then use the temperature web form to do a manual look up of the temperature? If so, then I suspect that they will “just work” with existing drivers.
Have you hooked one up and attempted to create child devices?
I just did that to see what happened and I got this in the log. Looks like it might be reporting as a Humidity sensor? I haven't loaded your humidity child driver but presumably it shouldn't report as a humidity sensor anyway? I can get the temperature OK from it via the web form in HA7Net.
UPDATE. I added the humidity child driver and created children again and it created a Humidity Child for the MS-T. Obviously not quite there - and humidity value is showing as 307.7, but it looks like it is at least communicating OK with the MS-T.
UPDATE to Update. Switched the driver to child temperature and working fine now
Since the current sensor identification logic in the parent is a kludge, I previously filed the following issue to enhance how sensors are identified and automatically associated with child drivers:
Once I implement this enhancement (perhaps this weekend), the parent will do a search of sensors associated with each of the supported family codes. For example, as long as the parent does a directed search for sensors of the family code 26 which represents the DS-2438 family of devices, the parent will automatically assign the standard temperature child driver to each sensor found based on that search. (Well, it's not that simple because the AAG TAI-8540 temp + humidity sensor uses a DS-2438 as its front end to the 1-Wire network. So each discovered DS-2438 will need to be inspected a bit further to determine whether it's a standalone temp sensor or also includes humidity).
I've updated the issue in GitHub to provide more details on which device family codes will be supported via the next update to the parent driver.
I'm happy to help test discovery of any of my devices once you've made the changes. I'm only playing around with them at the moment so can easily remove and re-install for testing.
Check out the other enhancements filed as issues in GitHub. After I enhance the discovery and child device mapping logic mentioned above, I'll tackle the following enhancement:
With my HA7Net, I see the web requests to the device fail on a sporadic basis. Here's one where all three attempts failed:
I had implemented some basic retry logic which seems to help, but in some cases the current max of 3 retires is exceeded and the drivers are not able to get sensor data that time around. Since it occurs sporadically, it's not the end of the world, but I am wondering if the current lack of concurrency management in the parent driver is the cause of the issue. Since the HA7Net supports concurrency management, making use of it in the parent driver is the "right thing" to do even if it doesn't solve the flaky behavior described here.
In this vein, could you post here the view source output of the humidity read from the HA7Net web UI for one of your DS2438Zs?
I'd like to see if there's anything in that output that would help the parent determine if it's not a temp + humidity situation and just a plain ole DS2438. Otherwise, I'll probably have to make use of some lower level interfaces to the HA7Net to distinguish between plain ole and the AAG TAI-8540 situations.
I've had one for many years and it "moved" with me every time I changed HA platform ..... I currently use mine with Node-Red.
I've not looked at your code or how it works, but on the issue of concurrency, I remember having similar issues when I first wrote some simple perl code to interrogate it.
I switched to using one call to the HA7NET to get ALL sensors in one go rather than retrieving each one individually. The HA7NET seems much happier with that, especially when there are many sensors attached.
I was even lazy on the returned data, as I just used a couple of quick regex to extract the results out of the html which helpfully has lots of ID fields in each table row.
Maybe something to look at if you haven't already!
Yes, I've taken that approach in other scripting with the HA7Net, but I'm not inclined use this approach for the Hubitat because I want to treat each child device independently so that, for example, when you refresh a child device, the associated device driver cares only about getting data for the associated 1-Wire sensor.
Additionally, since there's a mix of temp only and temp + humidity devices in our home, we'd have to have multiple sets of en masse queries depending on the sensor type.
I also don't think that approach fully addresses the concurrency challenge if multiple threads on the Hubitat call for interaction with the HA7Net at the same time, a person hits the web UI and/or there are other clients in the environment screen scrapping the web UI.
Could you delete some of your DS2438 child devices, install the new parent and child drivers from master in my GitHub repo and execute the createChildren command on the parent?
Your standalone DS2438 sensors should be identified as temperature only devices and be associated with the temperature only child driver.
You should no longer need to have the temperature-h and humidity child drivers installed before executing the createChildren command on the parent.
Lock Idle Timeout
See the updated README.md file for a new section on adjusting the lock idle timeout on the HA7Net to minimize read timeout occurrences when the child drivers are refreshing their sensor readings. I've been running with 5 seconds most of today and things look good thus far. No read timeouts just yet.
Background
I enhanced the parent driver to distinguish between standalone temperature only DS2438 sensors like you have and DS2438 sensors that are part of combined temperature + humidity sensors such as the AAG TAI-8540 sensors that I have.
The checking logic is pretty kludgy - checking for humidity above 150%, but it should work for now and not require you to install the other child drivers. I've left open the associated issue in GitHub until I can figure out a more reliable means of distinguishing between these situations.
I also implemented support for using 1-Wire family device codes to more directly discover different families of sensors. That new logic just helps us isolate DS2438 sensors so that we can do focus on distinguishing amongst those vs also worrying about DS18S20 and DS18B20 temperature only sensors.
Expanded Testing
I plan to order some DS18B20 and DS2438 sensors so that I can directly test those sensors with these drivers. I currently have only DS18S20 and the AAG sensors.
New device identified correctly as Temperature device. It automatically selected the temperature child driver and was given the device label "EB000000BCF62726 - DS2438 Temperature"
I've changed the read timeout to 5 seconds as you suggested, but I hadn't noticed any errors before anyway to be honest. I only have 2 sensors currently active on HE and refresh them both every 6 minutes currently.
Thanks for your work on this and let me know if you want me to do any more tests.
@ckamps I have now gone to the next stage and am using one of my DS18S20s as the main sensor for my Heating Control. It seems much quicker to respond than any of the Zigbee temperature sensors that I was previously using so gives a much tighter range for the heating hysteresis.
One thing that did bother me slightly though, with it being dependant on a connection to another hub, was what would happen if the sensor didn't respond to update the temperature, either if my router or the HA7Net went down or if a cable was damaged etc.
In my case, if the boiler was on, it would just keep running which obviously isn't ideal. I thought about a few different ways to deal with the possibility but having looked at your child temperature driver I ended up just adding a few extra lines to it that send a reading of 99 Deg C if a sensor cannot be contacted. That means it would fail-safe and the heating would turn off. I appreciate that not every user would want this feature (you might be using it for A/C control and you would want the opposite effect) but if anyone is interested in the fail-safe option for heating I added these lines after line no 44 where it deals with a failure to read a sensor.
I've tested it by disconnecting the router cable to the HA7Net and it works well.
I also created an HE rule that looks out for a temp of 99 on the sensor and sends a pushover to me to let me know it's happened. I guess if I wanted to get really smart, I could have HE switch back to using my Zigbee Sensors for the heating if the HA7Net had been out for a while, but I haven't done that yet.
Nice. Do you mind filling a new issue in the GitHub repo for this capability so that we can better track it and make it more visible?
If you’re familiar with git and want to create a pull request to submit the changes, feel free to do that too.
As for the general scenario, this must be pretty common situation independent of the sensor infrastructure for which I hope that there’s some dialogue that has already taken place in this community to arrive at best practices. For example, I wonder if use of last update data for the given device could factor into decision making within rules.
Since I have a similar situation with the operation of our whole house humidifier during winter, I'm going to take a look at use of the lastUpdated attribute in the associated rule,
