Premise Zwave sensors

[mhilbush]

I have not had a chance to look at the config commands above.

PS: Here's some fan data we should explore adding. The original module built by 123 was designed with the Wayne Dalton thermostat in mind and the WD did not offer fan setting status over z-wave. To figure out whether the fan is actually running or not, we would need logic that combines the Fan ON or AUTO setting and whether HeatingStatus is heating, cooling or off.

Set to FAN ON:
[1844] OnChangeOnNewData(): <3/27/2011 2:22:29 PM> rxtextline=<N003:069,003,001
[1844] OnChangeOnNewData(): <3/27/2011 2:22:29 PM> Unknown Node General command: from node=3, rxText=<N003:069,003,001
[1844] OnChangeOnNewData(): <3/27/2011 2:22:29 PM> rxtextline=<N003:068,003,001

Set to FAN AUTO:
[1844] OnChangeOnNewData(): <3/27/2011 2:23:28 PM> rxtextline=<N003:069,003,000
[1844] OnChangeOnNewData(): <3/27/2011 2:23:28 PM> Unknown Node General command: from node=3, rxText=<N003:069,003,000
[1844] OnChangeOnNewData(): <3/27/2011 2:23:29 PM> rxtextline=<N003:068,003,000

From what I can tell, this is the THERMOSTAT_FAN_STATE command class.

The GET command would look something like this: >N3SE69,2 and would result in a REPORT command

The REPORT command would look like the above <N003:069,003,001 or <N003:069,003,000 and could be sent unsolicited or in response to a GET command.

The most significant 4 bits of the last byte are reserved. The least significant 4 bits are the fan operating state, and can be one of:

0     Idle
1     Running / Running low - Lower speed is selected in case it is a two-speed fan
2     Running High - High speed is selected in case it is a two-speed fan
3-15  Reserved for future use

 

[mhilbush]

From what I can tell, this is the THERMOSTAT_FAN_STATE command class.

The GET command would look something like this: >N3SE69,2 and would result in a REPORT command

The REPORT command would look like the above <N003:069,003,001 or <N003:069,003,000 and could be sent unsolicited or in response to a GET command.

The most significant 4 bits of the last byte are reserved. The least significant 4 bits are the fan operating state, and can be one of:

0     Idle
1     Running / Running low - Lower speed is selected in case it is a two-speed fan
2     Running High - High speed is selected in case it is a two-speed fan
3-15  Reserved for future use

Do you think it's as easy as creating a ProcessCmd_ThermostatFanState method that sets Thermostat.FanStatus to On or Off if the THERMOSTAT_FAN_STATE report is non-zero or zero, respectively? Note that Thermostat.FanStatus is readonly, so it appears to be there for exactly this purpose.

 

[etc6849]

You're right... What you're saying explains everything What was messing my logic up is after manually changing the fan mode from on to auto, I wasn't waiting long enough for the fan to go off (this takes a few minutes). This meant the reported fan state didn't match the immediate fan state, but would after a few minutes.

Here's the additions I'm proposing for the thermostat. Thermostat process command methods could be made more generic, but only if we know of other types of devices that use the same z-wave commands classes...? Attached is the XDO, open it in notepad++ and copy the changes listed below. I've tested it with the Trane/Schlage/RCS z-wave thermostat and fan state reports work automatically with or without polling.

I never did catch the mysterious triggering of multilevel sensor again, it could have been me as at one point I manually added a multilevel sensor. I have a 1.4MB debugview log if you're interested PM me an email address. ProcessCmd_Configuration still needs to account for thermostat mode settings (hold, energy saver, run etc...), right now it ignores thermostat mode. This may be worth ignoring if the codes aren't standardized though (e.g. the <N003:112,006,xxx,001,xxx commands).

1. Change OnChangeOnNewData to call SetThermostatFanMode for aParms(1)=69

					case 69: 'THERMOSTAT_FAN_STATE
						if iParms = 4 and aParms(2) = 3 then 
							this.Devices.SetThermostatFanState aParms(0), aParms(3)
						end if

2. Make a ProcessCmd_ThermostatFanState method so that fan state is more generic (I don't know if a different type of device uses fan states, the two z-wave fan controllers I have show up as dimmers) OR use SetThermostatFanState with the small change below.

'
' NOTE: Do not know the total number of Z-Wave fan states.
'
' Z-Wave Fan State codes:
' 	Off = 0 
' 	On = 1
'	Others States?
' Premise FanStatus codes:
' 	Off = 0
'	On = 1

dim oDevice

set oDevice = this.GetDeviceByNodeID(method.NodeID)
if not oDevice is nothing then
	oDevice.receivingUpdate = true
	
	' If there are more than two Z-Wave fan states,
	' this next line may fail!
	if method.State = 0 then
		oDevice.FanStatus = method.State
	else
		oDevice.FanStatus = 1	
	end if

	oDevice.receivingUpdate = false
	set oDevice = nothing
end if

2. Add a new boolean with a default of true called SupportsFanState to the Thermostat class. The user would manually set this to false if they are using the Wayne Dalton thermostat.

3. Add a OnChangeHeatingStatus to thermostat that looks like this:

' If fan status is auto and thermostat does not support fanstate
if this.FanControl = 0 and this.SupportsFanState = false then
	if sysevent.newVal = 4 then
		' Unit must be off, so fan must be off
		this.FanStatus = 0
	else
		' Unit must be on, so fan must be on
		this.FanStatus = 1
	end if
end if

4. Add OnChangeFanControl:

'
' Premise FanControl codes:
' 	Auto = 0 
' 	On = 1
' Z-Wave Fan Mode codes:
' 	Auto/Auto Low = 0 
' 	On/On Low = 1
' 	Auto High = 2
'	On High = 3
'

if this.ReceivingUpdate = false then
	this.Parent.Parent.SendCommand ">N" & this.NodeID & "SE68,1," & this.FanControl, true, this.NodeID ' High-priority
end if

' If thermostat does not support fan state and fan control is set to ON, set fanStatus to ON
if this.FanControl = 1 and this.SupportsFanState = false then
	this.FanStatus = 1
elseif this.SupportsFanState = false then
	if this.HeatingStatus = 4 then
		' Unit must be off, so fan must be off
		this.FanStatus = 0
	else
		' Unit must be on, so fan must be on
		this.FanStatus = 1
	end if
end if

 

[chucklyons]

Does the Z-Wave driver work with Schlage, kwikset or other Z-Wave enabled door lock systems? Or does this work with just a select few devices? Would this module have to be tailored to bring other devices into support?

We're almost there with the purchase of the new house, so I need to make these important decisions soon!

 

[etc6849]

No lock support yet as these require beaming. A new VRC0P will be coming out that supports beaming and support for locks will be added then!

Z-Wave is a generic technology, so unless the device requires beaming (only certain devices like locks do), the device should work or can be made to. Many types of devices work with this driver thanks to Mark and 123: dimmers, switches, fan speed controllers (when modeled as a dimmer), temp and humidity sensors, motion sensors, door sensors and thermostats.

 

[mhilbush]

No lock support yet as these require beaming. A new VRC0P will be coming out that supports beaming and support for locks will be added then!

Z-Wave is a generic technology, so unless the device requires beaming (only certain devices like locks do), the device should work or can be made to. Many types of devices work with this driver thanks to Mark and 123: dimmers, switches, fan speed controllers (when modeled as a dimmer), temp and humidity sensors, motion sensors, door sensors and thermostats.

The current list of sensors that work with the driver are:
HM-TS001 - HomeManageables Temperature/Humidity Sensor
HM-DW001 - HomeManageables Door/Window Sensor
HM-FS001 - HomeManageables Flood Sensor (no longer produced by manufacturer)
ZIR000 - ACT Motion Sensor
HSM100 - Homeseer motion, light, and temperature sensor
HRDS1 - Hawking Door/Window Sensor (same functionality as HM-DW001)
SM103 - Everspring Door/Window Sensor (same functionality as HM-DW001)

Most of the framework is there to add just about any other sensor device as long as it fully conforms to the zwave protocol, and there's some documentation that describes it's config parameters.

 

[etc6849]

Mark, you really added a lot to this module... Your work is very nice and much appreciated! I can't wait to see what else you add to the final version

I'm curious if you have a Vera and if you've tried the VRC0P emulation plug-in? It's in beta, but I think you can download it from their site (I don't have a Vera or I'd try it). The plug-in is one potential way to use z-wave locks with Premise (assuming Vera's emulated protocol allows for lock control). The plug-in is in beta and I haven't read anyone using it...

Chuck: another option would be to contact homeseer and see if they'd supply you with the protocol for the z-troller:
http://store.homeseer.com/store/Z-Troller---Z-Wave-Primary-Controller-PC-Interface-HomeSeer-P214C44.aspx

If homeseer would give you their z-troller RS232 protocol docs (which they may not as they may want people to use their software instead of a free option like Premise), you could build a module for using z-wave locks via the z-troller. This could be done in builder pretty easily and you could even use 80-90% of the VRC0P's module as a template

 

[mhilbush]

Mark, you really added a lot to this module... Your work is very nice and much appreciated! I can't wait to see what else you add to the final version

Posting a work-in-progress. It's running cleanly in 2 separate Premise installations. I feel it's reasonably stable, but probably not defect free.

View attachment Vizia final v15.zip

A lot of changes in this version. The big ones are:
- incorporated etc's thermostat fan state changes described above. I went with the ProcessCmd_ThermostatFanState method, rather than SetThermostatFanState. Even though this command class is specific to thermostats, in general, I think it's a good idea to keep the details of how the command class works inside the method that supports the command class. It also has the benefit of keeping OnChangeOnNewData relatively lean and manageable. If this module continues to grow to support more device types, OnChangeOnNewData could get unwieldy.
- reorganized the classes for models and sensor types into their own module within the main module. This will help keep the main module from getting too cluttered, especially if the models and sensor types grow.
- speaking of models, I made some extensions to the main Device class to hold the output of the VERSION and MANUFACTURER_SPECIFIC command classes. This allows the model self-discovery functionality used on sensors to also be used on non-sensor devices. This will come in handy if there are config parameters we want to set for non-sensor devices (such as thermostats!).
- also extended ImportDeviceNames to include functionality to allow self-discovery of model information for non-sensor devices. This is enabled through the boolean Identity.EnableModelDiscovery. I followed the same timer methodology that is used for name discovery. As it stands now, model discovery occurs at time of device discovery for non-battery powered devices, and at wakeup time for battery-powered devices. This seems to make the best sense.
- added a few models for non-sensor devices.

I can't quite figure out DigitalInputEx versus DigitalInput. DigitalInputEx looks like it has a property that allows the state to be inverted, which I find handy. However, setting Invert to true doesn't seem to make any difference in the value of the State property...

I'm curious if you have a Vera and if you've tried the VRC0P emulation plug-in? It's in beta, but I think you can download it from their site (I don't have a Vera or I'd try it). The plug-in is one potential way to use z-wave locks with Premise (assuming Vera's emulated protocol allows for lock control). The plug-in is in beta and I haven't read anyone using it...

No, I don't have a Vera!

I did pick up a couple of the TZMT400 thermostats. Now, I just need to find some time to get them installed. Does anyone happen to have any documentation that describes the configuration parameters supported by this device? At a minimum, it would be good to understand parameters 25 and 132 from further up in this thread.

 

[etc6849]

Thanks for all of the improvements! I'll look over your code this week when I get a chance.

 

[Odeen]

Hi Markh,

In the ProcessCmd_ThermostatFanState method, you set FanState to be either True or False. It seems that when FanState is true, and you look at the thermostat in the Devices section, the FanState will actually be "-1".

Setting FanState to false results in it showing up as "Off"

I changed the code to set FanState to 1 or 0 (instead of true and false), and that corrected the -1 behavior. FanState at 1 shows up as "On" in the device monitoring section.

 

[etc6849]

Hi Odeen!

Good catch, the code should be an integer 0 for "Off" and 1 for "On." I'm very surprised vbscript doesn't correctly interpret the code as I think it would work fine under most languages? (I'm not a programmer though) True = -1 for vbscript it seems and this is by design!

FYI: for others following along at home...
If you navigate to sys://Schema/Device/FanStatus you will see the possible values for fan state: on or off. This class is called an "Enumeration." Enumerations are special containers with children that are enum objects, the name of which can be referenced by a value. In SYS, enumerations are referenced by properties of type "MultiValue." In this case the MultiValue property is found under the class sys://Schema/Device/ClimateControl and is called FanStatus.

More information can be found under Premise Builder help by searching for "MultiValue Property Type":
Setting value in Scripts:
'Using string name of Enum.
home.Basement.Thermostat.TemperatureMode = "Heat"
'
'Using numerical value assigned to Enum.
home.Basement.Thermostat.TemperatureMode = 1

Notes:
Each choice in a MultiValue property is called an Enum, which is an element of an Enumeration. The Enumeration is an object containing the possible choices for a MultiValue type property. Each Enum has a name and a numerical value assigned to it. The Enums in the Enumeration, are ordered from least numerical value to greatest numerical value, though they do not have to be numbered 0, 1, 2, 3 etc. It is also important to note that the first Enum in a list may have a numerical value of 0. Refer to Classes for more information about Enumerations.

 

[mhilbush]

Ok. Fixed in the attached version.

Do either of you guys happen to have a doc that describes the config parameters supported by the TZMT400 thermostat?

 

[etc6849]

Mark, thanks for the quick fixes! Are you referring to the commands with parameters 25 and 132? I can call Leviton and see if they can explain those.

I hope we don't have this issue when the new VRC0P comes out with lock support. I was counting on Leviton updating their protocol document... The new VRC0P will start shipping May 1st (talked to a Leviton rep here: http://communities.leviton.com/thread/1960?tstart=0 )! The problem is, you have to wait for whatever place you buy it from to run out of the old version If all goes well, we can download a new programming guide next month.

Ok. Fixed in the attached version.

Do either of you guys happen to have a doc that describes the config parameters supported by the TZMT400 thermostat?

 

[mhilbush]

Mark, thanks for the quick fixes! Are you referring to the commands with parameters 25 and 132? I can call Leviton and see if they can explain those.

Yes, those two at a minimum. Preferably, I'm looking for a description of all the configuration parameters (including #25 and #132) supported by the device through command class CONFIGURATION (i.e. 112). I don't believe Leviton will have these, as they are device/manufacturer specific.

 

[etc6849]

Try this doc out (scroll to bottom of pdf for config class variables): http://oldsite.rcstechnology.com/docs/thermostats/zwave/TZ43%20INSTALLATION%20MANUAL%20141-01652-04.pdf

I know it says RCS, but I have a "theory" that the Trane tstat is very similar to the much more expensive RCS version. It contains parameter 25 and many others, but no 132... Still researching 132

EDIT: I'll have to call RCS next week and talk to them about config parameter 132. I think all other config parameters are there

Also, here is some interesting info about the thermsotat's capabilities:
http://forum.micasaverde.com/index.php?action=printpage;topic=1801.0

Kind of a teaser since AsiHome never posted the config parameters they were using to perform the actions.