Premise Z-Wave Status using RZCOP/VRCOP help

[etc6849]

Thanks 123, nice work! All appears to be working as before.

I have no idea how you can look through Builder's IDE to find every call for sencCommand, addJob and runJob... Are you making these changes to the xdo file using a text editor? I could never figure out an easy way to do this type of thing in Builder...

Is it worth while to have each job carry information on what object is related to the job using the reference property? Right now it looks like the object type is stored (ie thermostat), if you were to reference the object the job relates to, it would be easy to have send command look through all jobs and delete the jobs with low priority related to the particular thermostat being sent the new command, thus skipping the incoming poll data. Right now the it seems the end goal is to delete all low priority commands related to any thermostat?

 

[etc6849]

There is a hardware anomaly that I'm just noticing and I'm not sure why it's happening. Note that the thermostat is not giving the heating set point of 74 degress for every poll, but does eventually give it on the third poll...? I am confused as to why this is happening and why it's giving the cooling set point twice?

>N28SE49,4
>N28SE49,4
<E000
>N28SE64,2
>N28SE64,2
<X000
<E000
>N28SE66,2
>N28SE66,2
<N028:049,005,001,009,068
<X000

<E000
>N28SE67,2,1
>N28SE67,2,1
<N028:064,003,001
<X000
<E000
>N28SE67,2,2
<X000
>N28SE67,2,2
<E000
>N28SE68,2
>N28SE68,2
>N28SE69,2
<X000
>N28SE69,2
<E000
<X000
<E000
<X000
<N028:067,003,002,009,062
<N028:067,003,002,009,062
>N28SE49,4
>N28SE49,4
<E000
<X000
>N28SE64,2
>N28SE64,2
<E000
>N28SE66,2
>N28SE66,2
<N028:049,005,001,009,068
<X000
<E000
>N28SE67,2,1
<X000>N28SE67,2,1

<E000

<N028:064,003,001
>N28SE67,2,2

>N28SE67,2,2
<X000
<E000
<N028:064,003>N28SE68,2
,001
>N28SE68,2
<X000
<E000
>N28SE69,2
<X000
>N28SE69,2
<E000
<X000
<N028:066,003,001
<N028:067,003,002,009,062
<N028:067,003,002,009,062
>N28SE49,4
>N28SE49,4
<E000
<X000
>N28SE64,2

>N28SE64,2
<E000
>N28SE66,2
>N28SE66,2
<X000
<E000
>N28SE67,2,1
>N28SE67,2,1
<X000
<E000
<N028:049,005,001,009,068
>N28SE67,2,2
>N28SE67,2,2
<N028:064,003,001
<N028:066,003,001

<X000
<E000
>N28SE68,2
>N28SE68,2
<X000
<E000

<N028:067,003,001,009,074
>N28SE69,2
>N28SE69,2
<X000
<E000
<X000
<N028:067,003,002,009,062
<N028:067,003,002,009,062

Another sample that seems to be ok except for the first poll:
>N28SE49,4
>N28SE49,4
<E000
<X000
>N28SE64,2

>N28SE64,2
<E000
>N28SE66,2
>N28SE66,2
<X000
<E000
>N28SE67,2,1

>N28SE67,2,1
<X000
<E000
<X000>N28SE67,2,2

>N28SE67,2,2
<E000
>N28SE68,2
<X000
>N28SE68,2
<E000
<N028:049,005,001,009,068
>N28SE69,2
>N28SE69,2
<N028:066,003,001
<N028:067,003,002,009,062
<X000
<E000
<X000
>N28SE49,4
>N28SE49,4
<E000
>N28SE64,2
<X000
>N28SE64,2
<E000
>N28SE66,2
>N28SE66,2
<X000
<E000
<N028:0>N28SE67,2,1
49,005,001,009,068
>N28SE67,2,1
<X000
<E000
<N028:064,003,001
>N28SE67,2,2
>N28SE67,2,2
<N028:064,003,001
<N028:066,003,001
<N028:067,003,001,009,074
<X000
<E000
>N28SE68,2
>N28SE68,2
<X000
<E000
<N028:067,003,001,009,074
>N28SE69,2
>N28SE69,2
<X000

<E000
<X000
<N028:067,003,002,009,062
>N28SE49,4
>N28SE49,4
<E000
>N28SE64,2
<X000
>N28SE64,2
<E000
>N28SE66,2
>N28SE66,2
<N028:049,005,001,009,069
<X000
<E000
>N28SE67,2,1
<X000
>N28SE67,2,1
<N028:064,003,001
<E000
>N28SE67,2,2
<X000
>N28SE67,2,2
<N028:066,003,001
<E000
>N28SE68,2
>N28SE68,2
<N028:067,003,001,009,074
<X000

<E000
>N28SE69,2
<X000>N28SE69,2

<E000
<N028:067,003,002,009,062
<N028:067,003,002,009,062
<X000
>N28SE49,4
>N28SE49,4
<E000
<X000
>N28SE64,2

>N28SE64,2
<E000
>N28SE66,2
>N28SE66,2
<X000
<E000
>N28SE67,2,1
<N028:049,005,001,009,069
>N28SE67,2,1
<X000
<E000
>N28SE67,2,2
<N028:064,003,001
>N28SE67,2,2
<N028:064,003,001
>N28SE68,2
<N028:066,003,00>N28SE68,2
1
<N028:067,003,001,009,074
<X000
<E000
>N28SE69,2
>N28SE69,2
<X000
<E000
<N028:067,003,001,009,074
<X000
<E000
<X000
>N28SE49,4
>N28SE49,4
<E000
<X000
>N28SE64,2

>N28SE64,2
<E000
>N28SE66,2
>N28SE66,2
<X000
<E000
>N28SE67,2,1
>N28SE67,2,1
<X000
<E000

<N028:064,003,001
>N28SE67,2,2
>N28SE67,2,2
<X000
<E000
>N28SE68,2
<X000
>N28SE68,2
<E000
>N28SE69,2
>N28SE69,2
<X000
<E000
<X000
<N028:064,003,001
<N028:066,003,001
<N028:067,003,002,009,062

 

[123]

... Are you making these changes to the xdo file using a text editor?

Yes. I use Notepad++.

Is it worth while to have each job carry information on what object is related to the job using the reference property?

That's a great idea and would allow the driver to purge low-priority jobs that apply to the single object, the thermostat, as opposed to all thermostats. The only reason I hesitate to implement this capability is that ProcessCurrentJob would requires more coding overhead to determine the object's class. Currently, it simply tests an integer value ... and that's very fast. We can make this driver ultra-sophisticated but at some point we get diminishing returns for our efforts ... how may Premise users are there and how many of them use Z-Wave and how many of those have two or more thermostats? (Answer: Zero).

 

[ASIHome]

etc6849,

Which thermostat are you using?

 

[123]

Wayne-Dalton WDTC-20 (mentioned a few posts ago).

 

[ASIHome]

I was just wondering as I don't see those kinds of delays/issues when polling using HyperTerminal. Is there a slowdown in your network somewhere? Does it still occur if your network consits of only the thermostat and the serial?

 

[123]

... Is there a slowdown in your network somewhere?..

You might be on to something. etc6849 did mention the following (Original Post):

... the Wayne Dalton thermostat seems to slow the two way feedback down a few seconds for nodes placed near the thermostat. This seems better than the home settings light I returned that was slowing feedback down 30 seconds though! I'm not sure why non-leviton devices slow the feedback down.

 

[manxam]

Excellent job you guys, keep up the good work!

Regarding the slow down, could this perhaps be the difference in speeds between 9.6kbps devices and 40.0kbps devices? Most of the original or less expensive zwave devices use the slower speeds.

M.

 

[etc6849]

Thanks guys for all of the ideas!

I know if I have an all vizia rf+ network there is a very short delay (1-3 seconds total) for receiving and reacting to the two way feedback from the manual operation of a switch/dimmer. My first issue was noticed with a dirt cheap (less than $20) home settings zwave socket style switch. This delayed the feedback 20-30 seconds. The WDTC-20 thermostat causes ~5-7 second delays for neighboring vizia rf+ devices and is acceptable as is.

To be clear, this is only an issue with the two way feedback function. I can send all devices a command and they react instantly so I wouldn't think it would be due to the speed differences (ie one way functionality is perfect). This is because the command must go node to node for one way commands, so if one way commands are fine, I wouldn't expect the baud rate differences to be an issue. Also, I have confirmed this is a hardware issue as port spy shows the delay. Perhaps a VZC0P instead of a RZC0P would fix my problem, I'm not sure... There is also a set route function in the RZC0P protocol that I can explore to solve this problem. I believe for vizia rf devices you can define a route, but I haven't tried this yet as I'm on travel again :lol:

My final solution may be to have two zwave networks in my home, one for vizia rf and another for non-leviton devices. Has anyone tried such a thing? Would I have to buy yet another handheld primary controller? Perhaps the solution here would be to purchase the USB stick below to setup the second network, then use the USB stick with Premise through a virtual com driver.

I was thinking about trying this guy here: http://store.homeseer.com/store/Z-STICK-S2...bs-P746C66.aspx What makes this USB adapter tempting is it also supports the new Schlage door locks and would avoid the monthly fees Schlage charges to give you lock status etc... I don't have any of the door locks yet, waiting for them to come down in price. Note it can be a "primary or secondary Z-Wave controller" so you would only need one of these devices instead of a handheld leviton controller plus a RZC0P. I doubt the Leviton two way feedback will work with it though, but I may borrow 123's code and modify it to work with this USB stick if I buy one. If I get one I'll post results here. I don't anticipate buying one anytime soon as I can live with a 5-7 second delay and I removed the home settings socket style switch a month ago.

 

[etc6849]

One thing I forgot to mention is in the final driver, I would disable this message if other people are getting it. Is anyone else seeing this pop up after logging back in SYS through builder after several days of z-wave polling?

I usually have two or so of them in queue when I log in so I click ignore all, not a big deal and it's happened with all releases that I can remember. I believe I receive them due to a serial port issue where a port reset is needed after a few thousand polls. See 123's code below:

if sysevent.newVal then
	this.InterfaceFailureTime = now
	this.ResetPort
	
	' Create an entry in the Premise Event Log
	dim oEvent
	set oEvent = Events.CreateObject(Schema.System.Event.Path, "Interface Failure")
	with oEvent
		.Description = this.Name & " experienced " & this.Jobs.MaxConsecutiveFailedJobs & " consecutive failed Jobs."
		.Severity = 50
		.EventTime = Now
		.LinkObject = this
	end with
	set oEvent = nothing
end if

It's not a z-wave driver issue as I have the same issue with a betabrite driver too. The z-wave driver is smart enough to reset the port for me which is very cool, and does so after x number of failed jobs. The z-wave driver is smart enough to also resend the failed job, and this is very neat too.

I have yet to see a non-dll driver for Premise that doesn't cause this issue with serial ports on my system, but no one on here besides me has ever had this problem. I still believe it's a security issue with Windows 7 and Vista causing the issue. Eventually I plan to make a 1u server just to run Premise and I'm going to use XP as I believe it will fix this issue altogether.

 

[123]

... Is anyone else seeing this pop up after logging back in SYS through builder ... I usually have two or so of them in queue when I log in ...

Those are Premise Events generated by the driver (with the code in the previous post) after it encounters two consecutive Job failures. It means the driver tried to send a ViziaRF command, failed after three attempts, then tried sending a second command and also failed three times. This kind of communication malfunction can be caused by several things such as a disconnected RZC0P, a very busy RZC0P, or a serial-port failure (which, as you've mentioned, appears to plague your system).

Premise Events is like Windows Events and is a logging facility for status messages (typically errors). By default, Premise Builder is configured to display these messages in a pop-up window upon login. However, you can disable this behaviour as follows:

1. In Builder's main menu select Tools > Configuration
2. Click the "Session" tab.
3. Disable EventPrompting then click OK

BTW
Whenever a Premise Event occurs you can optionally have it trigger a Premise Alarm (search Premise Help for "Alarms"). Alarms can send email notifications and run scripts to perform other actions.

 

[etc6849]

123, thanks for the lesson on events and alarms. I love the idea of Alarms; this sounds like a very useful feature I haven't used yet!

It seems you are using an event in case of a hardware failure, but an event could be that you are away on vacation and motion is sensed, or the temperature in the home has dropped below freezing, etc...? An alarm handler sounds like a useful way to trigger email notifications for such events.

 

[ASIHome]

Just so you guys know, the differences between the RZC0P and the VRC0P are the logo on the front and the part number.

 

[etc6849]

EDIT: The comments below are probably me not understanding the driver fully... However, I'm still interested in the scenario found below, any comments? My problem turned out to be hardware related; the rs232 zwave module needed to be unplugged then plugged back in? I had to have my wife do this because I'm not at home...

I had a question about the drivers architecture:
What resets Interface Failure once it has been set? Perhaps onChangeInit should set Interface Failure back to false after the reset port method is triggered?

My theory on a possible problem: if you have two interface failures, the serial port will be reset on the first because Interface Failure will go from false to true. The next time Interface Failure is set to true, no new data will occur (Interface Failure is still true) and the scrip to reset the serial port will not fire.

I have added a temporary change to the drivers onchangeinit script (last line):

' Configure the serial port
this.Baud = 9600
this.DataBits = 8
this.Parity = "None"
this.StopBits = 0
this.FlowControl = "None"
this.RTS = "Enable"
this.DTR = "Enable"
this.CTS = False
this.DSR = False
this.RxMode = True
this.RxTextLineTerminators = "0D OA"
this.InterfaceFailure = false

I see one danger in this change: with the new line above, could the driver get stuck in an infinite loop due to a true hardware failure (such as a cable failure)? Could this lock up Premise as the vbscript interpreter runs in single thread? Is this why you have left this line of code out?

 

[123]

.. What resets Interface Failure once it has been set?..

It works the way it was proposed in this post. The only difference is that the flag is now called InterfaceFailure as opposed to CommunicationFailure:

... if the driver fails to successfully transmit 2 consecutive Jobs (that's 2 Jobs x 3 repetitions per Job = 6 consecutive failed commands) that it'd be safe to conclude there's a communications problem and the driver should set the CommunicationFailure flag. If the next Job completes successfully, it will clear the CommunicationFailure flag.

A successfully transmitted command is evidence that the Interface (i.e. the RZC0P) is working properly. If the Interface is accepting commands, then the InterfaceFailure flag is cleared. The technique you've described is based on the assumption that a port-reset will cure the transmission problem.

BTW, the ability to recover from a communication problem (by automatically resetting the serial-port) is a technique that I've never see implemented in any other Premise driver. In other words, this driver goes beyond the norm in order to accomodate the serial-port headaches you're experiencing.

The serial-port problems you are experiencing are abnormal. The only thing positive about these wonky ports is that they make a good test-bed for writing and testing fault-tolerant drivers. Other than that, there's something fundamentally wrong if they must be reset every few days. I think you already know that and I wish I had a quick fix to this problem but I don't. If it were happening to me, I'd try running everything on a different PC. I don't think this is OS-related because people are running Premise successfully on Win XP, WHS, and Vista.