Basic driver development questions (HA7Net and 1-Wire)

Since I didn't find an existing driver, I'm in the early stages of developing a driver for HA7Net devices . I've looked at a lot of driver examples, but I still have some basic questions about how I should be implementing an HE driver for this device. These questions are less about dealing with the HA7Net specifically and more about working with devices that need to be polled for information.


Since creating this post, I've worked through the majority of the issues I was facing with this driver. The initial iteration is working for both standalone temperature and combined humidity and temperature sensors supported by the HA7Net.

The released HA7Net drivers were announced in this thread:

A few highlights on my learning:

  • The 500 error was due to a @Grab statement that was attempting to include an external library. I've since removed that statement in deference to relying on the httpPost() method to automatically parse the HTML response.
  • Once I got past the 500 error, useful error messages were displayed when I attempted to add the driver to HE.
  • Since I didn't initially realize that the built-in httpPost method existed, I was attempting to use the package to support the POST operation. Since this package is not allowed on HE, I migrated to using the built-in httpPost() method.

Driver Code in Development

Here's the working driver code:


Q: Target End User Experience

Update: I'm planning to get the basic driver working and then quickly migrate to implementing a parent-child driver so that the HA7Net device is treated as a parent device and children devices are automatically created for each sensor known to the parent HA7Net.

I assume that once I get this driver deployed and tested, the end user experience will be for the user to:

  1. Deploy the temperature + humidity and/or the temperature only driver(s).
  2. Create a virtual device for each 1-Wire sensor and associate one of the two drivers with each of those virtual devices.
    • Enter the unique sensor ID.
    • Enter the HA7Net's IP address.
    • Assign a name to the virtual device that represents the location and perhaps the type of the sensor.
  3. Define one or more rules in RM to force a periodic refresh of the devices' status.
  4. Implement other rules to take actions based on temperature and humidity values being reported by the sensors.

Does this sound right in terms of overall user experience?

If there was sufficient metadata for each sensor maintained in the HA7Net, for example, the logical name and location of each sensor, then I could see developing an HE app to auto discover and register the sensors as virtual devices. However, there is insufficient metadata managed in HA7Net.

Q: Including External Modules

Update: Unfortunately, but understandably, use of @Grab does not appear to be supported in HE. The good news is that the built-in method httpPost automatically parses the HTML response.

Is the use of @Grab to grab external modules supported in HE drivers?

Since this driver does screen scrapping of HTML responses from the HA7Net, I'm using a tagsoup XML parser that is more lenient that stock parsers.

Q: Required Methods

In the case of this type of device where Hubitat will need to poll the HA7Net to obtain sensor data, what is the minimum set of methods needed in the driver?

  • install(), updated(), and initialize() - I implemented these methods, but they are very basic.
  • refresh() - Already implemented with the code to send a POST to the HA7Net and send events back to HE, but I have a question (see next one) about how to properly send the required data back to HE.
  • poll() - It looks like I should implement the poll() method and simply have it call refresh().
  • parse() - I've seen other drivers implement the parse() method, but this method seems to be needed for devices that proactively send data. I'm assuming that this method does not apply to the HA7Net.

Q: Sending Data Back to Hubitat

Update: The `sendEvent() method appears to be working as expected.

The driver's refresh() method is currently using sendEvent() to send temperature and humidity data back to HE. Is this the proper way to send data back to HE in this scenario?

I've declared the following capabilities for this driver:

  • RelativeHumidityMeasurement
  • TemperatureMeasurement
  • Refresh.

Q: Debugging Error 500 Issues

Update: After removing the @Grab line, the 500 error went away and useful error messages started appearing. I'll consider filing a bug with HE about generation of a 500 error under this circumstance.

Is there anything I can do to help debug the 500 error when registering this driver?

The logs don't appear to have any data in them related to failed addition of the driver.

Device Background

An HA7Net device can support up to 100 1-Wire sensors. It has an ethernet interface and a built-in web application that enables a browser-based view of sensor data. To obtain sensor data, client applications need to perform screen scrapping via POST requests including whether the request is for temperature only or temperature + humidity data and the sensor ID.

The 1-Wire devices I currently have on hand are:

  • AAG TAI-8540 - Humidity + temperature (includes an embedded DS18B20 temp sensor)
  • DS18B20 - Temperature

Hi @ckamps,

I'm still relatively new to developing on HE myself, but have been able to setup a few drivers that integrate with systems like Philips Hue and some cloud based API's

I can't answer a number of your questions, but a few points I can make from my own experience / understanding...

You seem to be on the right track with the capabilities and working with these and the relevant methods. I setup a driver for SensorPush temp/humidity sensors and did what I think your describing with a rule calling the refresh method on a 1 min time schedule. The refresh method called another method which did the API call to get some json data in my case. I then use the sendEvent call like you mentioned to update the appropriate attribute for temperature or humidity.

I constructed my driver as a single driver representing the sensor push system, which was used for a virtual device. I then dynamically created child devices under the one "sensorpush" parent device, using the virtual temperature and virtual humidity drivers for each child sensor. The single driver for the parent device maintained the attributes on the child devices using the send event like I mentioned earlier.

In terms of the user experience, keep it simple while you are starting out. You could consider looking at dynamically creating devices initially without a description (or with a temporary one) and sending some kind of notification to the user to log in and update the new device details. Just a thought.

I'm on my mobile typing this, so haven't tried to provide any examples, but if you want more details on what I've done just let me know.


Hi @sburke781,

Thanks for the response!

Agreed. I'm going to get this simplistic version of the driver working first and then I'll enhance it to take the parent-child approach where the parent device will represent a particular HA7Net device and a series of children devices will be created automatically based on introspecting the HA7Net for the list of currently known sensors. To your point, the children will get default names that the user can modify later on to better represent the role of each sensor device.

Thanks again.


Do you have a SensorPush driver or know where I can find one sburke???

1 Like

If you have a gateway I wrote one to retrieve the readings via their cloud api.

I have the gateway and will take a gander. thank you very much.

1 Like


Just an FYI - I have been making some modifications to my SensorPush driver today. I'll setup a separate thread with a link to the updated code.


Awesome! Thanks for the post and update.

1 Like

Here's the link

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.