Premise Question about bindings

[mhilbush]

I could use a little help understanding how bindings work.

I'm extending etc6849's Vizia driver to support sensors. I've run into a behavior that I don't understand, and would appreciate some guidance.

I've created a Sensor base class that inherits from DigitalInput. The intention is to inherit from the Sensor class in order to create a number of other classes:
- BinarySensor (used for handling devices that provide a binary on/off state, such as the Everspring SM103 door/window sensor or the ACT ZIR000 motion sensor)
- AlarmSensor (used for handling devices that provide an alarm condition, in addition to the binary on/off state, such as HM-FS001 flood sensor)
- MultilevelSensor (used for handling sensors that report multiple readings, such as the HSM100, which reports motion, temperature, and luminance)

I'm running into a problem with my MultilevelSensor class. MultilevelSensor inherits from Sensor (so it picks up State from DigitalInput), TemperatureSensor, HumiditySensor, and LightSensor). Within the driver module, I can set all the properties that the zwave sensor reports -- in this case the HSM100 reports motion, temp, and luminance. This part is working very well.

The problem arises when I try to bind a MultilevelSensor object to a Home object. In testing this, when I create TemperatureSensor, LightSensor, and MotionSensor objects under Home, I run into a problem when I bind these to a MultilevelSensor device object. TemperatureSensor gets bound to the device's State and Temperature properties, while LightSensor gets bound to the device's State and Light properties. This causes the Home objects' Temperature and Light properties to be corrupted when State changes.

Here's a picture of what I mean. I've highlighted the areas of interest. The binding of Temperature to State doesn't seem right. And, I can't figure out how to delete the Temperature-State binding. You also can see how the Temperature reading got mangled when the State property changed.


Thanks for any help.

 

[etc6849]

I'm not sure of an easy way to fix the problem. Too bad 123 isn't here (he built the VRC0P module not me)

This is what I think is happening
Sensor inherits from Device which inherits from BindingTarget. Home objects then inherit from BindingSource; this is what allows them to bind with device types inheriting from BindingTarget. Also, in order for properties to bind, the Bindable attribute must be set to true for that property.

What you have created is an object with many properties, three of which have bindable attributes. This normally works fine, except that apparently a Boolean property is compatible with a Percent property in that SYS will bind the two! This results in SYS binding two properties with the Home object's Temperature property. Perhaps SYS is averaging the temperature sensor value with -461.47 F, which is what the Boolean value gives alone...?

A possible solution?
MultiLevelSensor should only inherit from the Container class. A Sensor object would always be created as a child "contained" within the container MultiValueSensor. You would also create two additional contained objects in the container: one that inherits from a new TemperatureSensor class and one that inherits from a new HumiditySensor class. Don't forget that each of these two new classes need to inherit from the Leviton Device class (else you wouldn't be able to bind them with home objects). To create a contained object, select ObjectContainment instead of Inherit under the class content pane. You would also need to modify the Devices class to contain MultiLevelSensor (kind of like a container within a container).

When a MultiLevelSensor is created, all three contained objects would be created. Sensor could still have the option for manufacturer specific models. However, this might be something that should be moved to the new MultiLevelSensor container? I'm not sure, but I don't know how this would affect your other uses of Sensor so you may not want to do this.

When a manufacturer specific model is picked, all three contained objects would automatically be edited as necessary. I would also add a null option to the multivalue property containing the model numbers. You'll also need to populate the device properties for all three contained objects (nodeID, oneway, etc...).

To bind with a home object, all that would now be needed is to drill into the container device object and select the appropriate contained object.

I've attached an example that just shows the structure I'm talking about. I didn't modify any code to work with this new structure. I know it will bind properly with the various home objects as I have manually added new devices and bound them. I'm not sure how many changes will be needed to your code, but I'm assuming this isn't a simple change

 

[mhilbush]

This is what I think is happening
Sensor inherits from Device which inherits from BindingTarget. This is what I think allows the binding with a home object. Home object's then inherit from BindingSource; this is what allows them to bind with device types inheriting from BindingTarget. Also, in order for properties to bind, the Bindable attribute must be set to true for that property.

What you have created is an object with many properties, three of which have bindable attributes. This normally works fine, except that apparently a Boolean property is compatible with a Percent property in that SYS will bind the two! This results in SYS binding two properties with the Home temperature object property called Temperature. Perhaps it is averaging the temperature sensor value with -461.47 F, which is what the Boolean value gives alone...?

I suspect you are right, and I see where you're headed with the suggested solution.

However, I thought the bindings were editable. Namely that there is a way to edit the connections in the Bindings tab. It would be much easier to just be able to delete the Temperature-State binding, leaving only the Temperature-Temperature binding. Is there something very basic that I'm missing here?

 

[etc6849]

For bindings that are manually made by dragging one property into another (right click on the home object then go to properties->binding), they appear as a green line. You can always undo bindings that are made manually by double clicking the green line. It will turn to red, click apply and the binding is gone.

Now, there may be a way to use vbscript and delete bindings that are automatically made. However, if you delete a binding that SYS automatically creates (assume this is accessible through vbscript), I am willing to bet it will recreate that binding if you reset the SYS windows service as it should load the XML and regenerate everything upon a restart.

 

[etc6849]

Example on how to delete a user made binding. The green binding turned red after I double clicked it. It should disappear altogether once I hit apply.

 

[mhilbush]

A Sensor object would always be created as a child "contained" within the container MultiValueSensor. You would also create two additional contained objects in the container: one that inherits from a new TemperatureSensor class and one that inherits from a new HumiditySensor class. Don't forget that each of these two new classes need to inherit from the Leviton Device class (else you wouldn't be able to bind them with home objects). To create a contained object, select ObjectContainment instead of Inherit under the class content pane. You would also need to modify the Devices class to contain MultiLevelSensor (kind of like a container within a container).

When a MultiLevelSensor is created, all three contained objects would be created. Sensor could still have the option for manufacturer specific models. However, this might be something that should be moved to the new MultiLevelSensor container? I'm not sure, but I don't know how this would affect your other uses of Sensor so you may not want to do this.

When a manufacturer specific model is picked, all three contained objects would automatically be edited as necessary. I would also add a null option to the multivalue property containing the model numbers. You'll also need to populate the device properties for all three contained objects (nodeID, oneway, etc...).

Thanks. I've explored your suggestion, and I think I have a solid approach. In fact, this approach will work to our advantage -- it will make it possible to autoconfigure all aspects of the sensors... Here's where I'm headed:
- Device discovery will create device objects of type BinarySensor, AlarmSensor, and MultilevelSensor.
- BinarySensor, AlarmSensor, and MultilevelSensor will inherit from a new class of device called BatteryDevice. BatteryDevice will inherit from Device; and will also inherit from Wakeup, so it will know how to deal with Wakeup and Battery commands.
- Upon receipt of a Wakeup command, the device will issue a MANUFACTURER_SPECIFIC get command. The MANUFACTURER_SPECIFIC response contains the manufacturer, product type and product ID of the device, which can be used to determine the correct Model object to associate with the device.
- Knowing the model means you know the capabilities of the device, which can be used to create one or more of SensorTypeBinary, SensorTypeAlarm, SensorTypeLight, SensorTypeTemperature, SensorTypeHumidity, etc. children objects
- These children objects are what you can bind to the Home objects.

I have most of this implemented, and it works REALLY well.

I'll post a fully functional version this weekend. I will still need to do some testing and cleanup, but what I post should be pretty solid.

I've also been running with the change to OnChangeOnNewData that handles the Network Reconfiguration command from the VRCOP. This change is working well, having eliminated the issue with devices being deleted when the VRCOP is updated from the primary controller.

        case 5: ' Network Reconfiguration (<!)
            sMsg = "Network Reconfiguration: " & aParms(0)
            'Do nothing with <!016; only kick off rediscovery on <!000
            if aParms(0) = 0 then
                this.Devices.DiscoverDevices = true
            end if

I'm seeing some strange behavior with device naming. The HSM100 supports naming, which is not the case for most of these battery-powered sensors. I can't quite explain what is happening here. The device is named Hsm, yet I'm getting this in response to the name request. Looking at the debug log, rxTextLine actually contains Hsm<E000.

 

[etc6849]

These are some great ideas for the layout; very logical! I look forward to your next release.

 

[etc6849]

I'm not sure what you'd need to change in order for naming to work right with the HSM-100. The current RxTextLineTerminator is "0D 0A" which means Premise waits for 0D or 0A or both before counting the transmission as new data...

It may very well be that Premise never see's 0D or 0A after the name is sent, so the line is only counted after <E000 is received (e.g. once the VRC0P acknowledges the command is successfully sent out). This issue is interesting as it seems to show that the HSM-100 responds to the request faster than the VRC0P can send <E000 to Premise and this messes up how the VRC0P send the name to Premise?!?

Since the VRC0P never uses a device name to issue a command, I don't think it's a big deal... However, any chance you could paste the raw hex data from port spy?

Other ideas
Try renaming the HSM100 through the VRC0P and Premise; this might fix the compatibility issue.

You also might unplug the VRC0P and plug it back in.

Send a PM to Tink (http://www.cocoontech.com/forums/index.php?showuser=187) or post the issue here: http://board.homeseer.com/forumdisplay.php?f=881

I'm pretty sure Tink works for Homeseer and develops their z-wave stuff.