Premise Z-Wave Status using RZCOP/VRCOP help

[123]

Have you actually witnessed this problem being resolved by toggling the OneWay flag? I ask because temporarily resetting a device's OneWay flag is (and no offense intended) an extremely inelegant technique, that is indiscrimanately applied to all OneWay z-wave devices, in order to compensate for a potential deficiency in one brand of thermostat. May I suggest that you comment out the OneWay toggling and try running the driver without it. If it proves to be necessary, you should 'special case' it ... in other words, toggle a device's OneWay flag but only if the device is a Thermostat.

 

[etc6849]

I agree, there is no way to know whether it is needed without testing. Obviously, my previous post is speculation at best

I know when I was using beta 9.6, a light would turn back on after I had toggled it off (if I was polling that light), but on rare occasions. I'm not sure why it was doing it. If I lowered the min PollingInterval to 5 seconds, I could get it to happen more frequently though. That's why I added the oneway timer to the lights and added a method to delete queued polls.

The one day I've been using 9.8 is not enough time for me to see if it does it again, but it seems to be working fine. When I get home, I'll use debugview and beta 9.6 to see if I can catch this issue and post it for you.

The problem could be... When a user turns the a vizia rf light on, then off, then on again a two way feedback status packet will be sent back for each toggle in addition to any polling responses. I'm not sure the RZC0P has any way to know which two way packet to send back first, let alone whether or not a polling packet is also received at around the same time. There's also no guarantee the packets will take the same path back to the RZC0P. The packets could potentially travel through different nodes making things worse.

 

[123]

etc6849,

Will you be posting a documented version of the z-wave driver in the Downloads section any time soon? We've both invested a great deal of time and effort in this driver and I'd like to see it officially available (i.e. documented and linked to Premise Wiki).

If not, let me know, and I'll take care of it.

 

[etc6849]

I'm not sure how to add a link to the Premise wiki, but I can add it to the downloads section. I ended up having to restore my Premise install to an older version, but I think I have found the last beta version I updated: beta 9.9 and have been using it again for several weeks. I still need to comment out the one way toggling within the dimmer/switch property changes before I post it.

 

[etc6849]

Forgot to mention: a few weeks ago when I restored SYS from an xdo file, I noticed the add-in named "Leviton" was also automatically added?!?

I believe there is some bug: if you have module name that matches an add-in name, the restore function within builder will enable the add-in unnecessarily...

EDIT: Try this test on a spare windows PC. Import the XDO by restoring from client. Prior to backing up to client, no add-ins were selected. The module names (Axis, Leviton, HAI) confuse the Premise restore feature and it enables the add-ins when it doesn't need to.

 

[etc6849]

123 any ideas on the add-in issue? Should I change the module class name? <_< I really liked the name Leviton...

Perhaps, it is easier to instruct users to delete the leviton dll file?

At any rate, I'm still gathering the documentation. I have a 9 page word file with all of your comments/additions! Obviously, I need to shorten this a little. Attached is an updated version of the driver. I commented out the brightness oneway flag timer as requested. I have not yet changed the module name until I get advice from an experienced user A job for Notepad++?

 

[123]

I may be wrong but I believe the "add-in" you described is Damon's Leviton Vizia RF driver (spLeviton.dll). It is a native driver (i.e. an "add-in") and resides in \Program Files\Premise\Sys\Bin\Devices.

You don't need two Vizia RF drivers installed so just delete spLeviton.dll. That should keep Premise from mixing them up.

 

[etc6849]

The add-in is part of the initial Premise installation. I remember before to use Damon's native vizia rf driver, I had to actually delete the dll for the leviton add-in that comes with Premise.

On a side note: the driver works, but as you noticed before, the rs232 output doesn't jive with the way onchangenewdata should work. I also had my RZC0P die on me last night (not related to the driver whatsoever, the RZC0P was dated 2006! Darn ebay!). I'll post some rs232 output next week when the VRC0P arrives. I may end up modifying the flow to wait for both Exxx and Xxxx before getting a new job. However, if I recall not all responses give both an E000 and X000. This will require adding a new property to a job that will indicate what the job is for: node command, group command, discovery etc... I can handle this update if you want to take a look when it's complete. I read somewhere that Johnny's driver actually retries a command on X002 being received; the driver currently does this for only Exxx errors.

 

[123]

While writing the driver, it seemed to me that the "X" command was the true indicator that a transmitted command had successfully propagated through the network. The "E" command simply acknowledges the transmitted command made it to the RZC0P. However, after looking through the logs you posted, it seemed that receipt of the "X" command was not guaranteed ... so I opted for the "E".

The driver's current mode of operation is to flag polling commands as being low-priority. Anything the end-user does is high-priority. When transmitting queued comamnds, the driver always sends the high-priority ones first. After transmitting a queued command, it waits for an "E" response. If one is not received within seconds, then it retries two more times before flagging the effort as a failure.

The principal exception to this rule is when the end-user adjusts a thermostat setting (i.e. creates a high-priority command), the driver purges all thermostat-related polling commands (i.e. low-priority commands) from the Job queue before sending the high-priority command.

If some commands generate an "X" response, and others do not, then you will definitely have to keep track of what type of command was sent and handle the response appropriately. Once you get the VRC0P you can experiment with the receipt mechanism and see if waiting for "X" makes the driver work better or worse. I think you may very well need to indicate each Job's precise purpose so that the driver can properly handle all of the exceptions you are uncovering.

Good luck!

 

[etc6849]

I was afraid of this and remember this being the case. In order to refresh my memory, I'm going to study the actual real world behavoir in detail.

Tying each job to received data sounds hard; especially since manual operation of a switch that will also result in receipt of data. I have some serious thinking to do about benefits versus time spent cause the driver works fine as is.

...
If some commands generate an "X" response, and others do not, then you will definitely have to keep track of what type of command was sent and handle the response appropriately. Once you get the VRC0P you can experiment with the receipt mechanism and see if waiting for "X" makes the driver work better or worse. I think you may very well need to indicate each Job's precise purpose so that the driver can properly handle all of the exceptions you are uncovering.

Good luck!

 

[etc6849]

Ok, I went and changed the batteries on the primary remote and bought a power supply for it. I think this could be part of the issue, but I doubt it. When the RZC0P dies, the light on it goes from blinking to solid green so I know this issue is hardware to do with the RZC0P. It then requires being unplugged from the outlet and plugged back in.

Attached are some several copies/pastes from Port Spy. The results are very encouraging to say the least. I'm still getting frequent X002 errors; however this is good cause I know my program flow is working (see attached txt file)!

I've tested the code below by adding/using Groups, Scenes, Discovery, Polling and node commands. I only had to add 4 lines of code! Port Spy shows a work of art that functions exactly as expected! Since the code was so well thought out before, it required little or no effort to change; good job 123!

				sMsg = "Error Status: " &  aParms(0)
				select case aParms(0)
					case 0: ' Acknowledgement
						this.Jobs.ConsecutiveFailedJobs = 0
						
[b]						if this.Devices.DiscoverDevices = true then[/b]
							this.Jobs.GetNextJob
[b]						end if[/b]
					case 1,2,3,4,5,6,7,8,9:
						this.Jobs.RetryJob
...
		case 2: ' Transmission Status (<X)
				sMsg = "Transmission Status: " & aParms(0)
[b]				if aParms(0) = 0 then
								this.Jobs.GetNextJob
				else[/b]	
																				this.TotalTransmissionErrors = this.TotalTransmissionErrors + 1
					this.Jobs.RetryJob
				end if
...
'this code was fine the way it was:
			case 4: ' Group Status (<M)
				sMsg = "Group Status: " & aParms(0)
				if aParms(0) = 0 then ' OK
					this.Jobs.ConsecutiveFailedJobs = 0
					this.Jobs.GetNextJob
				else ' Not OK
					this.Jobs.RetryJob
				end if

Here's the new flow:
Scene: Waits for M000 (get next job) or Mxxx (retry job)
Group: Waits for X000 or Xxxx
Manual commands: Waits for X000 or Xxxx
Discovery: Waits for E000 (get next job)

Note that Exxx errors still result in a job retry as I believe they should (if for no reason other than it shortens the code to keep it this way).

I think before we were confused because the Xxxx commands came in well after the command is sent. It was hard to group them visually so it appeared some commands had no Xxxx replies. I believe the Xxxx reply should occur unless the driver is using Scenes or "Discovering Devices." Of course I'll post this updated version and lengthy ascii command history this weekend or next week. Hopefully the RS232 module doesn't die again; else I'll have to test it in a week when the new VRC0P arrives. It will be interesting to see if the VRC0P gives the same X002 errors.

 

[etc6849]

My VRC0P arrived today. The Vizia RF+ works great. The two way feedback issue I had is completely gone; manually operated lights now send two way feedback in less than 2 seconds. X002 errors are still present though, but not as frequent (probably by a factor of 10 less). I actually could not catch a X002 error in the attached document.

I believe the X002 errors can be fixed by optimizing the signal strengths of each node. I've also got the ControlThink software and stick coming (10 days or so); I plan reset my network using it. Leviton owns ControlThink now, so I'm sure the USB stick will be invaluable for programming. Reading online, it has invaluable troubleshooting info such as signal strength at each node and etc... Had I known what I was doing originally, I would have bought the VRC0P and the ControlThink usb stick, skipping the handheld remote altogether.

I'd like to wait until I've tried the ControlThink stick as the primary controller before I publish the premise zwave manual. I'm thinking the manual should also have a few equipement recommendations such as how to set up a Premise zwave network: what's needed, reliability, expected rs232 output etc...

PS attached is rs232 output for all the commands/options of the Premise zwave driver with comments.

 

[123]

I reviewed the log file and its shows a very clean record of communications! The response to virtually all transmitted commands is "<E000" followed by "<X000". Picture perfect!

It is clear from the log that during the Discovery phase, one cannot expect to receive a "<X000" response. During Discovery, the VRC0P is being queried exclusively; nothing is being transmitted over the z-wave network so none of the queries respond with an "<X000" transmision confirmation.

That's something to keep in mind if you plan to modify the driver so that, after sending a command, it waits for the "<X000" response instead of "<E000". It'll have to be extra clever and forego looking for "<X000" responses after sending a Discovery-related command. You'll have to decide if the programming effort is worth the payback.

 

[etc6849]

I already programmed the changes; that's why the log file looks so clean See my Apr 12 post above for code changes... Only four lines of code total!

I reviewed the log file and its shows a very clean record of communications! The response to virtually all transmitted commands is "<E000" followed by "<X000". Picture perfect!

It is clear from the log that during the Discovery phase, one cannot expect to receive a "<X000" response. During Discovery, the VRC0P is being queried exclusively; nothing is being transmitted over the z-wave network so none of the queries respond with an "<X000" transmision confirmation.

That's something to keep in mind if you plan to modify the driver so that, after sending a command, it waits for the "<X000" response instead of "<E000". It'll have to be extra clever and forego looking for "<X000" responses after sending a Discovery-related command. You'll have to decide if the programming effort is worth the payback.

 

[123]

I already programmed the changes; that's why the log file looks so clean ..

Shame on me! Now you know that I had skipped the commentary in your post and went straight to examining the log file!

Well done! I think the driver now has enough fine-grained control to reliably handle most of z-wave and VRC0P's quirks. Maybe after another week or two of testing in your home it'll be ready for release?



For those of you who have just jumped in on this thread (now running at ten pages), we've co-developed a Premise z-wave driver for the VRC0P that supports lighting (including Groups and Scenes) and thermostats. The driver is:

• Fully Premise compliant.
• Implemented as a Module (all source code is visible).
• Selectively polls devices to determine their status.
• Uses an intelligent queuing mechanism to ensure commands are transmitted and received correctly.
• Resets the serial port when needed.