Premise Midon Design's TEMP08 driver

I thought the community might pool their knowledge and help kmitchell create a driver for the TEMP08. Providing 1-wire support for Premise would be a major contribution. Building a Module-based driver is a useful skill and I hope this thread will help others gain a better understand of the design process.

I don't have a TEMP08 but I had a quick look at its command set (page 9) and a sample program in VBScript. Here are my thoughts:

• One parent and many children
  The driver would consist of a Parent object (handles serial communications and global TEMP08 settings) and Child objects (individual 1-wire devices).
• Children inherit from existing Premise classes
  Each Child object inherits an existing Premise Home class that best defines the Child's purpose. A DS18S20 Temperature Sensor would be represented by the TemperatureSensor class, a DS2438 Humidity Sensor by the HumiditySensor class, and a DS2450 Voltage Sensors by the AnalogInput class. Some 1-wire devices, like the DS2423 Lightning counter, do not have corresponding Premise classes. The driver may have to create a corresponding Premise Home class.
• Parent: TEMP08 class
  The TEMP08 class will have several properties than control the physical TEMP08's operation. For example, the TEMP08 has an adjustable polling interval for reporting back the status of attached devices ("PollingInterval": Integer Value). It can also display temperatures in Fahrenheit or Celsius ("TemperatureScale": MultiValue) and set its internal clock ("ClockSync": Boolean, sync to PC's clock).
• Child: 1-wire Device class
  Each child object inherits from a base class (PremiseOneWireDevice or "POWDevice") that holds, at minimum, the 1-wire device's serial number.
• Auto-Discovery
  The driver can use this to "discover" what's connected and automatically generate the appropriate POWDevices.
• Auto-Removal
  The TEMP08 reports when a 1-wire device is removed. Handling this condition requires making a design decision. If the physical 1-wire device is gone, should the driver automatically remove the POWDevice? Or should it set some property in POWDevice ("Status" or "Enabled") to indicate there's a problem? Removing the dead POWDevice is simple and quick but it may be an overkill if the physical 1-wire device simply suffered a momentary hiccup and comes back to life on the next polling cycle. Alternately, the driver could indicate a problem only after the third consecutive report that the physical device is missing (assuming the TEMP08 reports a missing device more than once).
• Watchdog
  The TEMP08 can be set to report the status of all devices every few seconds. A Watchdog timer should be reset each time the status report arrives. If the Watchodog is allowed to run out, it indicates a status report failed to arrive and it may indicate the TEMP08 has failed or is disconnected. The Watchodog should indicate the problem (perhaps via an "Enabled" Boolean property in the TEMP08 class) and reset itself.

Thanks 123 for starting this thread.

I only had a little time last week to work on the driver but I expect to have more time this week.

So far I have the Temp08 Parent class defined with the Class Constructor, OnInit, and OnNewData scripts working. I also have properties defined for PollingInterval, TemperatureScale, and ClockSync as well as the property change scripts that send the commands to the Temp08. Right now the OnNewData script is just outputting the readings using "debugout" as I just started working on the 1-wire device class so your post is very timely.

Thanks again,
Ken

Ken,

You beat me to the punch!

I've attached my version of the driver for your use. It includes validation code for PollingInterval, TemperatureScale, and SyncClock and it sends the appropriate command strings. It sets those parameters upon port initialization and also asks the TEMP08 for a status report. Received data is simply echoed to the debug console.

The MacroFolder contains a script that demonstrate show to iterate through the child objects. Instead of using "GetObjectsByType", you'll probably want to use "GetObjectsByTypeAndPropertyValue" in order to retrieve a specific child object (where the property would be the device's SerialNumber or maybe SensorID). The idea being that when you receive incoming data, from a 1-wire device, you'll have to find the associated child object and set its value accordingly.

Good luck with the driver!

PS
Nuts. It's supposed to be MidonDesign not MidonSystem. Oh well.

ADDENDUM
I changed my Module's name to MidonDesign and incorporated the code from your module's OnChangeNewData method (see attachment). You can import it alongside your module (Midon_Design) without any problem (they have different names, GUIDs, etc). Have a look at how the properties are validated using OnChange scripts. Premise lets you build a very robust driver user-interface where properties can be validated to assure data quality.

Here's mine so far. It doesn't have the child classes yet as I just started working on that.

Let me know if I'm doing OK and don't laugh at all my mistakes.

Ken

PS. It's good you called your's MidonSystem that way I can load both modules and easily tell the difference.

FYI, I attached an updated version, in the first post, that incorporates some of your code. Overall the two modules were very similar with the exception that you had more code in OnChangeNewData and I had included several validation scripts for several properties.

Thanks for starting this project.

Let me know if I can do anything to help.

Mitch

midon said:

Thanks for starting this project.

Let me know if I can do anything to help.

Mitch

Click to expand...

Hi Mitch,

It's been awhile since we talked. Thanks for the offer to help. We're going to need some help testing since neither 123 nor I have a TEMP08. I have a TEMP05 but it only has DS1820 temp sensors attached.

Ken

One of the responsibilities of a device driver is to monitor its connection with the device and report dropped connections. The simplest method of fulfilling this responsibility is to use a 'Watchdog timer'.

A Watchdog is a countdown timer that, when things are working well, is never allowed to count down to zero. The Watchdog is reset by each successful communications exchange between the driver and the device. However, if there's a communications failure, the Watchdog counts down to zero and triggers an error message.

This concept is implemented in the latest version of the TEMP08 driver and consists of the methods highlighted in the attached image.

OnChangeOnInit
This method is triggered whenever the communications port is opened. Among many other things, it asks the TEMP08 to send a status report and starts the Watchdog timer.

GetWatchdogName
A timer needs a unique name. You can't simply call it "Watchdog" because if you load two instances of the same driver they will have identical timer names. This method simply returns a unique timer name.

CreateWatchdogTimer
This method simply creates a timer. If the timer already exists, calling this method will reset it. The timer's period is 2.5 times longer than the TEMP08's PollingInterval. If the TEMP08 report the status of all 1-wire devices every 30 seconds, the Watchdog runs for 75 seconds. If the TEMP08 reports back in 30 seconds, it resets the Watchdog timer. If it fails to report back twice in a row, the Watchdog will countdown to zero and trigger an error condition.

DeleteWatchdogTimer
This method deletes the Watchdog. It is used when you purposely close the communications port (i.e. change "Network" from "COM1" to nothing). There's no need for the Watchdog if you explicitly 'disconnect' the driver.

WatchdogTimedOut
This method is executed whenever the Watchdog timer counts down to zero (i.e. 'times out'). It sets the driver's "CommunicationsFailure" property to True and then resets the Watchdog.

OnChangeCommunicationsFailure
This method is triggered by changes to the CommunicationsFailure property. When set to True, this method logs an Event to Premise's event log. As with any Event, you can create an Alarm that will send email when the event occurs.

OnChangePortStatus
This method is triggered by changes to the communications port. It will delete the Watchdog when the communications port is closed.

Ken,
The attached file contains the latest TEMP08 driver with support for the Watchdog timer. During development, it is more convenient if the Watchdog is disabled. This can be done by commenting it out in the OnChangeOnInit method where it is initialized.

kmitchell said:

midon said:

Thanks for starting this project.

Let me know if I can do anything to help.

Mitch

Click to expand...

Hi Mitch,

It's been awhile since we talked. Thanks for the offer to help. We're going to need some help testing since neither 123 nor I have a TEMP08. I have a TEMP05 but it only has DS1820 temp sensors attached.

Ken

Click to expand...

Hi Ken (and 123),

Please contact me directly (email address is in my profile) and let's see what we can work out.

Mitch

Any update on this? Can I assume its good to go? (before I buy a Midon Temp08)....Pool season is almost over and I need to justify my purchase (well, rationalize is a better word!)

Chuck,

I'm embarrassed to say that I haven't progressed at all on this. I'd been off work a couple of months and right about the time a started working on it I got a contract job and things have been crazy ever since. I'll get a hold of Mitch tonight and make arrangements to get some test hardware so I can continue to work on it.

I'll solicit 123's help when I'm ready to test so I'm sure between us we'll have something working for you.

Sorry for the delay,
Ken

Ken,

No sweat! Glad to hear you've picked up some work. Times are tough - I felt your pain after the dot-com bust...which was an impetus for me getting into the HA racket...(I actually made $ doing this!)

Let me know if I can give you a hand - I have some free cycles, willing to buy a Midon, and am anxious to get that pool temp thing going! B)

Did anything ever happen with this or is this topic dead on the vine? Before I attempt to pick it up, I wanted to make sure I'm not going to duplicate work....

I bought one and promised Mitch that I'd write a driver. At the moment I'm busy with my Omnistat2 driver; the TEMP08 is next. I've reviewed its documentation and I have a good idea of what's involved in developing an appropriate parser.

The Temp08 is just one of many 1-wire interfaces available. It provides a device model where there is some degree of configurabilty and this can be extended. I'm only mentioning it from the perspective of how generalized you want to be. For example. The Temp08 implements a counter which has two channels and this counter can be used from some built-in functionality and for some extented functionality. The counter can be used to deliver a wind speed measurement where the count to speed transformation is done withing the Temp08. It can also be used to what is advertised as a lightining counter, but in reality is a simple one pulse per count measurement device. This can be connected to a variety of things such as a power meter or a rain bucket etc. Do you want the user to see counts (as presented by the Temp08) or do you want the use to see number of gallons counted for a water meter application? What about meters that have 0.1 gallons per count vs. 1.0 gallons per count or other measures? Is data presented on total counts since installation or is is reset at some interval sucha s daily? Do you derive additional information for the user such as count rate (e.g. water flow rate)?

I'm not trying to provide any direction, but just trying to disclose some considerations that I have run into doing my software for Temp08 and other devices. I started with Temp05 and found that when I went to a more capable device of the DS9097U that my initial design was constrained due to the close relationship to how a Temp05 works.