Premise MultiSensors? Any updates to VRC0P driver for modern Z-wave Devices?

Motorola Premise

doczaius

Member
Have there been any updates to the Vizia driver?  Or is anyone willing to share an export of something they have built on?  I thought I might ask before I spend any more hours trying to get these multisensors that I purchased to work.  The code for multilevelsensors that is in the posted driver is incomplete.  I purchased some in bulk that do motion & temp, and have been slowly acquiring the newest models from Aeotec which include 6 different sensor types (motion, luminance, humidity, temp, ultraviolet and vibration)... but I haven't even been able to get the binary sensor portion to work with either the ones from Vision Security or Aeotec. 
 
Any help is appreciated!!  
 
Are you referring to the ViziaRF driver written by etc6849 and me?
 
If so, I've had scare little time over the last couple years, so I've not touched (or even looked at) the code in a while.  IIRC, Temperature, Humidity, and Luminance are supported for a small number of Zwave devices.  
 
Going from memory here...  I recall it's not too hard to add additional devices.  There's some setup to add the device, then to create a mapping from the device to the sensor readings that the device emits.  To set up the device, the codes for Manufacturer, Product Type, and Product ID are needed.
 
IIRC, motion is handled using the BASIC command set versus the other sensors, which are handled using the SENSOR_MULTILEVEL command set.
 
I'd really need to refamiliarize myself with the code to provide better guidance.  I'll try to take a look at the code this week.
 
Of course, if you were referring to a driver different from the one etc and I wrote, disregard the above...
 
Hello!
 
 
markh said:
Are you referring to the ViziaRF driver written by etc6849 and me?
 
If so, I've had scare little time over the last couple years, so I've not touched (or even looked at) the code in a while.  IIRC, Temperature, Humidity, and Luminance are supported for a small number of Zwave devices.  
 
Going from memory here...  I recall it's not too hard to add additional devices.  There's some setup to add the device, then to create a mapping from the device to the sensor readings that the device emits.  To set up the device, the codes for Manufacturer, Product Type, and Product ID are needed.
 
IIRC, motion is handled using the BASIC command set versus the other sensors, which are handled using the SENSOR_MULTILEVEL command set.
 
I'd really need to refamiliarize myself with the code to provide better guidance.  I'll try to take a look at the code this week.
 
Of course, if you were referring to a driver different from the one etc and I wrote, disregard the above...
 
Hi Mark,
 
Yes was referring to the ViziaRF driver that you two built.  My Premise installation crashed a couple of years ago and its taken me that long to get the desire to rebuild all of the intelligent occupancy automation I had built/written.  With the advent of Zwave+ and decreased battery drain from these sorts of devices, new Multisensors are starting to appear from manufacturers like Aeotech and Fibaro.  I do not have a Fibaro though the seem to be selling alot as there is a significant amount of forum noise for some of the other automation solutions out there.  The Aeotech however is a fantastic little device.  The problem I have encountered is that it issues notifications over a number of different command classes.  A lot of the data is transmitted over the Security command class which is largely unimplemented in the ViziaRF driver.   Additionally items like temperature, though handled by the multisensor command class, transmit parameters in different formats and it seems that specific coding for the various models out there would be necessary.  I have tried to fiddle with this, but I'm not sure I completely understand the relationship between creating new device models with specific code and the actual/parent device.  
 
I would imagine that with more and more people jumping on the bandwagon with easy interface products like Wink, Iris, Nest etc, we will begin to see more and more of these sorts of devices that provide extended environment information.
 
I wonder if it might be prudent to look into creating some sort of connector to the OpenZWave library that is maintained by a wide audience of developers and contributors.  Many of these new model devices are already spec'd out and defined in that library.  
 
I know there are many solutions out there that would require a lot less effort to get up and running, but I have not found anything thus far that comes close holding a candle to Premise's object model and scripting capabilities.  Vera is too limited and Homeseer is an absolute joke. I got it on sale for something like $300 only to find that it doesn't natively support anything more complex than an If -> Then statement. How absurd.  Many of the other solutions that have popped up in the past couple of years are little more than glorified universal remotes, with actual automation,  (like climate management), if even offered is being off loaded to the cloud where the end user has no control.
 
Anyways, I would appreciate your thoughts.
 
Thanks!
 
So today you are still using Premise for automation.  That is good. 
 
Here too I have played with a variety of software and firmware automation devices and have yet to find something in software better than Homeseer. 
 
I have not had issues running Homeseer since 1998 here.  (well and using my OmniPro stuff since the early 2000's).
 
Heavy machine is running fine connected to some 16 plus hardware controllers running plugins, scripts, triggers totally way over 1500 today.
 
Did you have issues understanding the basics of Homeseer or does it not provide enough bang for the money for you?
 
What specifically causes your grief with Homeseer?
 
Here also played/playing with OpenHab (impressive), Echo, Kinect and Securifi stuff.
 
I haven't had any problems with HomeSeer, what works oob, works.. I do wish their Linux/BSD support was better, or existent, but that went out the window when they decided to develop HS3 in .Net instead of a more platform portable language.  Running HS3 over mono on raspberry pi 3's is so silly.
 
Bang for the buck is definitely a problem.  Homeseer has a lot of features, but to be frank a lot of the implementation is half-ass. Third party plugins/purchases are necessary to bridge the gap.. and when you've already dropped a brick on HS3Pro, spending another $30 for each different device that HS doesn't support is not a welcome feeling. 
 
I recently tried to re-develop my occupancy module I developed in Premise in HomeSeer. Going over the forums using virtual devices was the key to success.  I quickly hit walls in my attempt:
  • No logic nesting
  • No case logic
  • Limited ability to reference the values of other objects to determine the course of action for another.
  • The need to create virtual devices to store values means your device list can get very big, very fast.
I understand of course, you don't have to get a 3rd party plugin for advanced scripting and object referencing, you can write scripts in vb.net (yuck) but this goes back to my half-ass grievance.  You can do the same with SmartThings in Python (yasss), except its $99 and has a seemingly more active group of "open" centric enthusiasts and hackers.
 
Anyways enough HS bashing... I'll need to check out OpenHAB.. last time I did it was little more than a mission statement. Though if I could.. (who's gonna stop me right?) one final grievance. The HA world is growing by leaps and bounds, but HS seems oblivious, stuck in the 90s.
 
I do wish their Linux/BSD support was better, or existent, but that went out the window when they decided to develop HS3 in .Net instead of a more platform portable language.  Running HS3 over mono on raspberry pi 3's is so silly.
 
You can utilize python, perl, bash scripts today with Homeseer running in Linux.  I do that as it is easier for me than dot net stuff.
 
HomeGenie is running in Mono and it is a very popular free software today.  I've been running my weather stations originally using Wintel stuff / Cumulus.  I was going to switch over to using WView in Linux and decided here to stay with Cumulus running in Mono.  It is doing fine.
 
Goofing a bit here with Lua / OpenWRT OS stuff and I am impressed with what you can do with it with so little.
 
Yeah here purchased first Homeseer for $29.95.  I did upgrade whenever.  Most of my HA investments though have been relating to hardware.
 
Third party plugins/purchases are necessary to bridge the gap.. and when you've already dropped a brick on HS3Pro, spending another $30 for each different device that HS doesn't support is not a welcome feeling.
 
Not really. 
 
There are many Homeseer users doing their own Homeseer stuff with their own scripts and their own plugins plugins (either private or public or free or paid).
 
my occupancy module I developed in Premise in HomeSeer...
 
I quickly hit walls in my attempt...
 
Understood.
 
Here played a bit with Homeseer / Occupancy testing with a nearby Homeseer plugin author (Jim Doolittle) way back in the early 2000's.  It worked OK for me back then.
 
It is what you are familiar with; but you cannot put a round peg in a square hole; never does work.
 
I'll need to check out OpenHAB.. last time I did it was little more than a mission statement. Though if I could.. (who's gonna stop me right?) one final grievance. The HA world is growing by leaps and bounds, but HS seems oblivious, stuck in the 90s.
 
Yeah check out OpenHAB again.  I haven't been there in a while but am there a bit mostly just reading stuff.  I am Pete there too.
 
Nah HS is not stuck in the 90's; really it isn't. 
 
Like Mark, I haven't touched the module in years as it just works.  I've read too many z-wave issues with Vera and many other platforms.  The solution 123, Mark and I built for Premise uses the elegant VRC0P protocol.
 
Eventually Mark or I will buy one of the newer z-wave multi-sensors that use secure packets.  This is less likely to happen for me unless I move since I use a wired security system I installed.  When and if I buy one for myself, I will add the capability for free though and post it ;)
 
All that is needed is to study how the zwave lock class uses the VRC0P's secure protocol (requires +3 version of the VRC0P), and then follow what Mark did for his sensors.  It is much easier to do this when you have the device though.
 
Newer sensors that use secure packets are going to require some new code more than likely.  This shouldn't take more than a 2-4 hours to implement and test.  If you absolutely need it to work, PM me and send me a sensor after we agree on an hourly rate.  I will not charge anything if I can't integrate the sensor, but I have contacts at Leviton, so even if it is a VRC0P issue (doubt it is), I can request a firmware update.  The PM at Leviton and his engineer I talked to in the past are very sharp; they even used the same Premise module for testing purposes when the first VRC0P+3 firmware had some issues.  They had the issue fixed in less than a week too, and it has been rock solid for me for years.  Compare that to the complaints you see here for other platforms...
 
doczaius said:
Hi Mark,
 
Yes was referring to the ViziaRF driver that you two built.  My Premise installation crashed a couple of years ago and its taken me that long to get the desire to rebuild all of the intelligent occupancy automation I had built/written.  With the advent of Zwave+ and decreased battery drain from these sorts of devices, new Multisensors are starting to appear from manufacturers like Aeotech and Fibaro.  I do not have a Fibaro though the seem to be selling alot as there is a significant amount of forum noise for some of the other automation solutions out there.  The Aeotech however is a fantastic little device.  The problem I have encountered is that it issues notifications over a number of different command classes.  A lot of the data is transmitted over the Security command class which is largely unimplemented in the ViziaRF driver.   Additionally items like temperature, though handled by the multisensor command class, transmit parameters in different formats and it seems that specific coding for the various models out there would be necessary.  I have tried to fiddle with this, but I'm not sure I completely understand the relationship between creating new device models with specific code and the actual/parent device.  
 
I would imagine that with more and more people jumping on the bandwagon with easy interface products like Wink, Iris, Nest etc, we will begin to see more and more of these sorts of devices that provide extended environment information.
 
I wonder if it might be prudent to look into creating some sort of connector to the OpenZWave library that is maintained by a wide audience of developers and contributors.  Many of these new model devices are already spec'd out and defined in that library.  
 
I know there are many solutions out there that would require a lot less effort to get up and running, but I have not found anything thus far that comes close holding a candle to Premise's object model and scripting capabilities.  Vera is too limited and Homeseer is an absolute joke. I got it on sale for something like $300 only to find that it doesn't natively support anything more complex than an If -> Then statement. How absurd.  Many of the other solutions that have popped up in the past couple of years are little more than glorified universal remotes, with actual automation,  (like climate management), if even offered is being off loaded to the cloud where the end user has no control.
 
Anyways, I would appreciate your thoughts.
 
Thanks!
 
I may take you up on the offer for developing out the multisensor.  I have two brands now, the one by Vision and the one by Aeotech.  I think I've gotten the Aeotech to process, mostly, but I'm still trying to figure out getting the sensor data back to the "room".  Temperature is ok, but UV, humidity etc are not yet working.
 
As far as the Vision Security multisensor I can't get even temp to work.  It seems its using an odd format for sending that data (5 parameters) and unfortunately I've been unable to locate any copies of the zensys doc out in the wild. 
 
etc6849 said:
Like Mark, I haven't touched the module in years as it just works.  I've read too many z-wave issues with Vera and many other platforms.  The solution 123, Mark and I built for Premise uses the elegant VRC0P protocol.
 
Eventually Mark or I will buy one of the newer z-wave multi-sensors that use secure packets.  This is less likely to happen for me unless I move since I use a wired security system I installed.  When and if I buy one for myself, I will add the capability for free though and post it ;)
 
All that is needed is to study how the zwave lock class uses the VRC0P's secure protocol (requires +3 version of the VRC0P), and then follow what Mark did for his sensors.  It is much easier to do this when you have the device though.
 
Newer sensors that use secure packets are going to require some new code more than likely.  This shouldn't take more than a 2-4 hours to implement and test.  If you absolutely need it to work, PM me and send me a sensor after we agree on an hourly rate.  I will not charge anything if I can't integrate the sensor, but I have contacts at Leviton, so even if it is a VRC0P issue (doubt it is), I can request a firmware update.  The PM at Leviton and his engineer I talked to in the past are very sharp; they even used the same Premise module for testing purposes when the first VRC0P+3 firmware had some issues.  They had the issue fixed in less than a week too, and it has been rock solid for me for years.  Compare that to the complaints you see here for other platforms...
 
Coincidentally, the box that runs my Premise server crashed recently.  Looks like a hardware problem because I can't even boot into the BIOS.  The drive is good, but I can't get it to boot up in a new box.  I get a BSOD on boot, I suppose because the XP drivers are not compatible with the newer chipsets.  As an interim step, I may install Windows 10 from scratch, then install Premise (is it possible to install Premise on Win10?), and then restore the Premise config (which fortunately is regularly backed up to Google Drive).
 
This also has forced me to look around at other available home automation software.  I took a look at openHAB, which is all open source Java and appears to be under very active development.  The rub, is that openHAB v2 is still in beta, and I'm finding the ZWave binding a little finicky.  OTOH, the Zwave binding developer is very responsive in adding new devices into the device database.  For the devices I've submitted so far, turnaround time has been a couple days.  I'm going to spend some more time with openHAB2 and see how that plays out.  If things stabilize, I'll likely start to migrate over to that platform.
 

The openHAB2 UI is a modern HTML5-based responsive design, which runs well on many form factors ranging from smartphones to traditional desktops and laptops.  Rules and scripting support looks pretty powerful, too.
 

I currently have openHAB2 running on Ubuntu 16.04 LTS on an industrial, fanless PC.  I also have the source code loaded into Eclipse, so I'm better able to identify problems and provide feedback to the developers.  I may even take a run at developing a binding for the GlobalCache iTach devices.  There's already a binding for the IR device, but it won't easily support the CC and SL devices.
 
 
 
doczaius said:
Hello!
 
 
 
Hi Mark,
 
Yes was referring to the ViziaRF driver that you two built.  My Premise installation crashed a couple of years ago and its taken me that long to get the desire to rebuild all of the intelligent occupancy automation I had built/written.  With the advent of Zwave+ and decreased battery drain from these sorts of devices, new Multisensors are starting to appear from manufacturers like Aeotech and Fibaro.  I do not have a Fibaro though the seem to be selling alot as there is a significant amount of forum noise for some of the other automation solutions out there.  The Aeotech however is a fantastic little device.  The problem I have encountered is that it issues notifications over a number of different command classes.  A lot of the data is transmitted over the Security command class which is largely unimplemented in the ViziaRF driver.   Additionally items like temperature, though handled by the multisensor command class, transmit parameters in different formats and it seems that specific coding for the various models out there would be necessary.  I have tried to fiddle with this, but I'm not sure I completely understand the relationship between creating new device models with specific code and the actual/parent device.  
 
I would imagine that with more and more people jumping on the bandwagon with easy interface products like Wink, Iris, Nest etc, we will begin to see more and more of these sorts of devices that provide extended environment information.
 
I wonder if it might be prudent to look into creating some sort of connector to the OpenZWave library that is maintained by a wide audience of developers and contributors.  Many of these new model devices are already spec'd out and defined in that library.  
 
I know there are many solutions out there that would require a lot less effort to get up and running, but I have not found anything thus far that comes close holding a candle to Premise's object model and scripting capabilities.  Vera is too limited and Homeseer is an absolute joke. I got it on sale for something like $300 only to find that it doesn't natively support anything more complex than an If -> Then statement. How absurd.  Many of the other solutions that have popped up in the past couple of years are little more than glorified universal remotes, with actual automation,  (like climate management), if even offered is being off loaded to the cloud where the end user has no control.
 
Anyways, I would appreciate your thoughts.
 
Thanks!
 
So thats two reccs for openhab... Gonna have to take a look.  Also looking at SmartThings, seems to be a very active dev community extending the $60 device beyond its oob capabilities. 
 
I was thinking if worse comes to worse, I could always build a connector to interface between Premise w/JSON or ASCII and a home automation controller like hs3, smartthings or maybe openhab... letting those controllers manage UI and the communities/developers manage the devices, leaving me to focus on the actual logic/automation.
 
 
markh said:
Coincidentally, the box that runs my Premise server crashed recently.  Looks like a hardware problem because I can't even boot into the BIOS.  The drive is good, but I can't get it to boot up in a new box.  I get a BSOD on boot, I suppose because the XP drivers are not compatible with the newer chipsets.  As an interim step, I may install Windows 10 from scratch, then install Premise (is it possible to install Premise on Win10?), and then restore the Premise config (which fortunately is regularly backed up to Google Drive).
 
This also has forced me to look around at other available home automation software.  I took a look at openHAB, which is all open source Java and appears to be under very active development.  The rub, is that openHAB v2 is still in beta, and I'm finding the ZWave binding a little finicky.  OTOH, the Zwave binding developer is very responsive in adding new devices into the device database.  For the devices I've submitted so far, turnaround time has been a couple days.  I'm going to spend some more time with openHAB2 and see how that plays out.  If things stabilize, I'll likely start to migrate over to that platform.
 

The openHAB2 UI is a modern HTML5-based responsive design, which runs well on many form factors ranging from smartphones to traditional desktops and laptops.  Rules and scripting support looks pretty powerful, too.
 

I currently have openHAB2 running on Ubuntu 16.04 LTS on an industrial, fanless PC.  I also have the source code loaded into Eclipse, so I'm better able to identify problems and provide feedback to the developers.  I may even take a run at developing a binding for the GlobalCache iTach devices.  There's already a binding for the IR device, but it won't easily support the CC and SL devices.
 
Back
Top