Premise Updating an already added driver that has new schema

[franky]

I've written a custom native driver in C++ and defined various classes, properties, etc. in the driver's XML resource which gets embedded in the driver's DLL. I installed the driver to SYS by going to the Builder's File/Addins/Devices UI. Now I've updated the driver and added more properties to the some of the classes defined by the driver's XML.

If I simply copy the new driver DLL over the old one, the new properties don't appear in the Builder UI. If I un-add the driver and then re-add the driver using the Builder's File/Addins/Devices UI, I lose all the bindings and other configuration I've done on the devices implemented by the driver.

Is there a procedure to update a native driver that keeps the existing bindings, etc. but will also pick up new schema? I suspect I'm overlooking some obvious steps for this.

Regards,
Frank

 

[123]

Not 100% certain about this one (I haven't had many updated native drivers to play with!): stop the Premise service, copy the new DLL over the old one, and then start the Premise service. I'm hoping that that the new properties will appear after Premise loads the (overwritten) DLL and reads its updated schema.

BTW, what does the driver do?

 

[franky]

The new properties are showing up now. I was already stopping prkernel, copying, and restarting prkernel but apparently that wasn't enough. I think the key to get it to pick up the new schema was to update the version number in the schema.

Regarding what the driver does- I've been using HomeSeer to control some Z-wave and Insteon devices since Premise didn't have any support for them. I cobbled together a HomeSeer plugin and Premise native driver that talk to each other to give Premise some very basic control over the HomeSeer devices. I have not read up on the latest status of the Z-wave and Insteon drivers that others have tried to put together for Premise; I suppose there's a reasonable chance it would be easier to simply use those rather than somehow get HomeSeer and Premise to communicate.

 

[etc6849]

The Premise Z-Wave driver is very stable and probably supports as many devices as the Homeseer driver. Some neat things that were added in the last year:

1. Full Z-Wave lock support (including usercodes, battery alerts etc...)
2. Zone and scene controllers. These are modeled as native Premise keypads; this lets you bind buttons on controllers to trigger events in Premise. With Leviton's 4 button zone controllers, I'm able to trigger upto 10 events (8 events if you don't want to use the dim/brt buttons). Still no LED control, but the buttons work well otherwise.
3. Support for window/door contacts, motion sensors and humidity sensors.

The driver is posted on code.google.com. More info is here:
http://www.cocoontech.com/forums/index.php?app=downloads&showfile=176

 

[chucklyons]

So I'm in the new house, ready to add Z-Wave. What do I need first? I'm looking for outlets, doorlocks, etc. What device should I use to limit the learning curve...

BTW< - getting Premise installed onto the new Win7 server was a royal pain...hadn't had the problem before...but finally ! Up and running!

 

[franky]

The Premise Z-Wave driver is very stable and probably supports as many devices as the Homeseer driver. Some neat things that were added in the last year:

1. Full Z-Wave lock support (including usercodes, battery alerts etc...)
2. Zone and scene controllers. These are modeled as native Premise keypads; this lets you bind buttons on controllers to trigger events in Premise. With Leviton's 4 button zone controllers, I'm able to trigger upto 10 events (8 events if you don't want to use the dim/brt buttons). Still no LED control, but the buttons work well otherwise.
3. Support for window/door contacts, motion sensors and humidity sensors.

The driver is posted on code.google.com. More info is here:
http://www.cocoontech.com/forums/index.php?app=downloads&showfile=176

Thanks for the info! Right now I'm using the HomeSeer Z-Wave controller. I wonder what it would take to add support for that.

Also, I noticed the install instruction say to delete the existing Modules.Leviton. Does this mean I'd have to rediscover devices and bind them again to home objects every time I incorporate an update to the XDO? (I realize this is probably more a deficiency in Premise, not necessarily the module.)

Aside, I haven't followed this forum for quite a while so I'm not sure what the current state of the Insteon support is on Premise. I know someone in this forum was working on one and I tried it long ago with marginal success. Maybe I'll search the posts.

 

[etc6849]

Yes, this is an important step since as you know if you install objects with duplicate GUIIDs, SYS will crash until you fix things. This is probably why SYS is making your remove your DLL too, but I'm not sure.

I should have recommended this before, but I always make an install scriptmacro that will bind the home objects to the device objects via vbscript. This way I don't have to do a lot of clicking when I delete and reinstall a module that may have 40 device objects that are bound to home objects (such as the ViziaRF module or the Elk M1G module). I found the most logical place for these types of custom macros to live is under Modules.Default.Macros... Other than under Default, I try to keep all modules and their code very generic. I'm interested in what the other more experienced users like you think about this methodology of binding things via a script.

WRT Discovery, it's automated so this part is very easy once you have a VRC0P that's properly configured

WRT to Homeseer Z-Troller: Yes it can be created if you sign a non-disclosure agreement with the OEM company who makes the Z-Troller ( http://www.expresscontrols.com ). The problem you'll find is that the Z-Wave protocol is a lot more complex than the ascii protocol the VRC0P uses. However, there is an open source API you could use called Open Z-Wave, but I'm not sure how far along they are with new things like lock support. If you don't use Open Z-Wave, I'm not sure others could legally use your code to add more devices either so it would have to be an add-in (not a module) to keep things legit.

Also, I noticed the install instruction say to delete the existing Modules.Leviton. Does this mean I'd have to rediscover devices and bind them again to home objects every time I incorporate an update to the XDO? (I realize this is probably more a deficiency in Premise, not necessarily the module.)

 

[chucklyons]

I searched for this mysterious VRC0P...NOW I see what I need....Paypal'd it and waiting for the mailman

 

[etc6849]

The problem is there are now three versions of the VRC0P/RZC0P. Only the newest supports locks and is upgradeable. You want to be sure you get one with a description like this (Leviton re-used the model numbers so that alone is not sufficient to go off of):

http://www.asihome.com/ASIshop/product_info.php?products_id=3437

EDIT: Chuck, I thought I replied to your post earlier in the week, but now realize I didn't, doh! I did go and make the download instructions more clear about needing v3 for lock support. I just hope you ordered the correct one :excl:

 

[manxam]

WRT to Homeseer Z-Troller: Yes it can be created if you sign a non-disclosure agreement with the OEM company who makes the Z-Troller ( http://www.expresscontrols.com ). The problem you'll find is that the Z-Wave protocol is a lot more complex than the ascii protocol the VRC0P uses. However, there is an open source API you could use called Open Z-Wave, but I'm not sure how far along they are with new things like lock support. If you don't use Open Z-Wave, I'm not sure others could legally use your code to add more devices either so it would have to be an add-in (not a module) to keep things legit.

Not that I expect someone to spend as much time building Ztroller support as you have for the VRCOP but as I previously posted (and attached the PDF) express controls also manufacturers the Cooper Aspire RF which is the same as the Ztroller. Cooper also freely gives access to the underlying ascii control set for integration purposes.

I'd love for someone to add Ztroller support as it's a primary controller unlike the VRCOP..

Cheers,
M

 

[etc6849]

I'm curious if you have a ztroller to try these commands with? I'm not sure that the Z-Troller is using such a simple protocol as documented in the Aspire RF version:
http://www.cooperindustries.com/content/dam/public/wiringdevices/products/documents/technical_specifications/aspirerf_adtechguide_100713.pdf

Another issue I see is the Aspire RF document doesn't talk about locks, but I know the Z-Troller supports locks.

If the Z-Troller doesn't use the Zensys protocol, but instead a higher level ascii protocol, it would be very easy to build a driver for Premise. You would use the ViziaRF driver as a base and make modifications to each class and the global parsing scripts.

 

[manxam]

Happen to know of a serial port "sniffer" that can sit between Homeseer and the z-troller so I can monitor the traffic?