Aeon Labs MultiSensor 6 ZW100-A

Agreed on need of an update. I bought 2 of these sensors and neither can be integrated as of yet.
I saw the software update as of yesterday and was bummed to see that these are still not yet supported.

Should I pack these things back up and settle for the Gen 5, or should I keep holding my breath.

Thanks for the info

Dear friends
Despite how much I love your work it is simply taking too long. I know as professional how fast the IoT world is and what a big effort you guys have to chew on.

This sensor is now on the market for 10 months, that's storage in this world. Can imagine Aeotec is already working on its successor....Pity support for this device was not in last weeks release.
Fed up with waiting I'm playing with my Raspberry again and the Z-way daughterboard. It recognized the ZW100 in five seconds. Next trick is to ensure the Raspberry can tell Indigo that one of the sensors is fired. Yesterday was not long enough to get that finished. It should work and I'm quite I get this working the next few days, but it feels not as the right thing to do. Indigo is the only master in the house and I'd like to rely on that.

Please guys keep up the good work and ensure support for the ZW100 way before the summer holidays so I can rely on it!

Amen. I am closing in on finishing my renovation and trying to determine if I have to discard the five ZW100-A's I got and go back and buy the 5's. Perhaps you could let us know if this is because you are backlogged, having the planned for Indigo 7, or what?

Thanks.

Brian

[matt (support)]

All new device support that requires new device definitions (they don't match any existing definitions) will be going into the next major release (v7) or later. We won't promise any specific functionality, nor can we give any ETAs, but we are hard at work on the next major release.

As a past designer of telecom hardware, I know the problems of letting the cat out of the bag early. I watched that kill a company once. They announced a new product before it was ready and then they ran into problems, making it about 6months late. Customers stopped buying old product waiting for the new product. Not a good thing.

OTOH, here we are mostly a bunch of experimenters and early adopters. We aren't going to abandon you. Knowing that you plan support for a particular device, clearly one that is as popular as the ZW100-A (there are a lots of posts in this thread), would help us make planning decisions. We aren't asking you for a commit date on 7.0, only if you know whether support for the ZW100-A will be in there. If so, I am willing to wait and I can go ahead and deploy the units in my house. If the answer is 'no' then I can make other decisions. It isn't going to change my plan to keep using Indigo.

(YMMV.)

[matt (support)]

No promises or commitments per company policy, but supporting Aeotec devices has always been and continues to be a high priority. Also I have this particular module about 2 feet away from my desk (but then again I have dozens of modules within feet of my desk ).

Hi Matt,

I do understand you have your company policy (and why) ... but I'm afraid I don't agree with it or Brian(?) saying that "we're" not going anywhere. Personally I'm rapidly losing patience with the lack of support of ~year old modules, not only because it's frustrating to have modules I've bought but can't use, but also because my regular suppliers don't seem to sell much indigo-compatible gear any more. It's also pretty time-consuming to have to flick back and forth between their webpages, and this forum, just to try to find something which will work.

I guess and hope that Indigo 7 is imminent and will fix the compatibility issues, but this is just a guess on my part. It'd really help me personally to have some sort of a clue of timescale ... I'm very tempted to start looking for alternatives, just in case this it will be months not days (or a couple of weeks), or that I still won't have support for e.g. the multisensor 6.

Anyway, a bit off topic I know (and apologies for the rant - in general I really love what the two of you have achieved, and find it very impressive), but I just had my whole family out at my house and really wanted to show it off.

Edit: I would really love if Indigo 7 lets us add our own devices. I can completely understand that it takes a while for you to validate the support of a new device, but if it took me a few hours it'd still be less time than I've wasted trying to find alternatives. At least it would let those of us who are technically minded / professional coders, try to resolve our own issues (and share them with the community).

I think that a lot of the problems with this particular module were (deliberately?) created by Aeon. Since I had the Vera for the Z-wave locks and they claimed to have it sorted out, I added the one I bought as an experiment on that controller... it took a couple of weeks of back and forth with tech support at BOTH Aeon and MiCasa to finally get it sorted out that (external to Aeon's Z-stick anyway; their Gen 5 likely has some proprietary code to integrate and translate their stuff) it appears as a different device when it's on battery power than when it's on USB power and the battery powered implementation responds to configuration commands but does not implement them, meaning I had to put it on USB and link the device to configure it, then relink it on battery power in order to put it outside for a weather sensor...and then I found that the published code Vera used for getting the UV sensor actually echos the standard LUX value (making it in actuality a "5 in 1" on the Vera). Whether there actually is a separate UV sensor that can return the real UV value will apparently have to wait till MiCasa or Matt cracks Aeon's programming or they actually correct the "defect" in their documentation. Someone commented in another thread that "Open" access like WIFI, Bluetooth, and Z-wave were far superior to "proprietary APIs", which misses the point; WIFI, Bluetooth, Z-Wave, Zigbey(sp), etc are communication protocols; it doesn't matter how Indigo or Vera or or Windows 10 or your web browser gets the information, if the manufacturer won't say what "Device 'abc' State 'xyz' = 123" MEANS, it's irrelevant whether you get it from a Z-wave packet, RFX433 signal, XML file, Bluetooth receiver, or Indian smoke signal, your web browser, Indigo controller, or homebrew FTP interpreter isn't going to be able to display it to you or let you tell the device to do what you want in response. Matt and Jay have been getting the raw Z-Wave data from this beast (as you note) for over a year... the problem is trying to write the translation tables from the XYZ=123 into a nice "Aeon Sensor UV level 185"...

As far as defining your own devices, the GhostXML Plugin adds quite a bit of capability there IF the device has a WIFI interface that you can persuade to dump the raw data in XML or JSON... even if the device is secure, you can probably (haven't tried it yet but may on the KEVO when I have time) add an authentication step to the Ghost source to unroll everything the device is putting out on the internet and cherry pick the info you need.

So, I think if I pair with Vera, Indigo bridge will not see this, is that right? (only lights and locks if I recall)

Will a virtual vera switch work with the indigo bridge? Please let us know. Thanks

If so, I can pair with Vera, and have vera flip the virtual switch, and if Indigo can see that virtual switch on vera via the bridge, I am ok on motion.. untill Indigo updates for this.

The Vera bridge plugin will see and control my Kwikset Z-wave ;lock, but not interact with the sensor directly... I don't know if it will see switches; I have none on my system. And I haven't looked into whether it can trigger and/or monitor Vera scenes, although there is supposed to be some ability to at least set Vera scenes from Indigo. The plugin that the current very bridge is based on is open sourced, so you could potentially hack it yourself to add capabilities, but, although I do know a bit of Python, would require a lot more programming time than I have available.

Got it...

Virtual switch did not work with the Indigo Vera bridge, BUT... I created a scene in vera that runs Luup to interact with Indigo:

luup.inet.wget('http://192.168.0.39:8176/actions/KitchenMotion?_method=execute')

A bit of a workaround, but hopefully they will get is supported soon : )

HI all,

Here is a quick and dirty way to get Indigo to support the new Aeon MultiSensor 6.

Set up a cron job to run every few minutes and execute the script below. It scans the log looking for the z-wave updates from the sensor, which do report lux, humidity, temp etc, but Indigo doesnt yet know what to do with the updates so they are ignored. The script below finds these and loads them into custom variables that you can then use.

I havent worked in the motion sensor updates yet, but you get the idea and I'm sure someone can get that working easily. My main focus was on the humidity reading.

The script is a quick hack, its not robust and I'm sure will break easily, but I wanted to show you all the concept, others can make it robust and steal the idea for other non-supported devices.

Code: Select all

# Scan log for MultiSenor6 ZWave Updates
# Load into variables

# Uses regular expressions
import re

# Number of log entires to go back through and scan
lines = 500

# Custom variables to use
# ****** UPDATE THIS PART ******
humid = indigo.variables[505508429] # "ZWHumid"
lux = indigo.variables[607265278] # "ZWLux"
temp = indigo.variables[37483596] # "ZWTemp"
# *******************************

# Get the last xxx log entires
indigo.server.log("MS6: Looking for Wine Cellar updates...")
logEntries = indigo.server.getEventLogList(lineCount=lines)

# Split by newline so we can process the array from newest message to oldest
log=logEntries.splitlines()
logs = len(log)

# This is the common text that comes back for the mulitsensor 6
# ****** UPDATE THIS TO MATCH YOUR DEVICE NAME *****
searchLine = 'received "Z-MS\(New\): Wine Cellar" sensor update to '
# **************************************************

# Look for Lux ---------------------
# Go backwards through log, newest to oldest
for logevent in reversed(log):   
   if re.search(searchLine + ".*lux", logevent):
     lux = logevent[78:80]
     indigo.server.log("  MS6: RegEx Lux found in eventLog: ["+lux+"]")
     # Load into the custom variable ****** UPDATE THIS PART ******
     indigo.variable.updateValue(607265278, value=lux)
     # Stop looking, we have the newest update, we dont want older ones
     break

for logevent in reversed(log):
   if re.search(searchLine + ".*%", logevent):
     humid = logevent[78:80]
     indigo.server.log("  MS6: RegEx Humidity found in eventLog: ["+humid+"]")
     indigo.variable.updateValue(505508429, value=humid) # "ZWHumid"
     break

for logevent in reversed(log):
   if re.search(searchLine + ".*C", logevent):
     temp = logevent[78:80]
     indigo.server.log("  MS6: RegEx Temperature found in eventLog: ["+temp+"]")
     indigo.variable.updateValue(37483596, value=temp) # "ZWTemp"
     break

indigo.server.log("MS6: Done")

Here is a quick and dirty way to get Indigo to support the new Aeon MultiSensor 6.

Thanks for the inspiration!

I altered your code a slight bit to grab the variables no matter their value and put the code in a schedule to fire off every 15 minutes:

Code: Select all

# Scan log for MultiSenor6 ZWave Updates
# Load into variables

# Uses regular expressions
import re

# Number of log entires to go back through and scan
lines = 500

# Custom variables to use
# ****** UPDATE THIS PART ******
humid = indigo.variables[104851327] # "ZWHumid"
lux = indigo.variables[96535918] # "ZWLux"
temp = indigo.variables[169923791] # "ZWTemp"
# *******************************

# Get the last xxx log entires
# indigo.server.log("MS6: Looking for Garage Sensor updates...")
logEntries = indigo.server.getEventLogList(lineCount=lines)

# Split by newline so we can process the array from newest message to oldest
log=logEntries.splitlines()
logs = len(log)

# This is the common text that comes back for the mulitsensor 6
# ****** UPDATE THIS TO MATCH YOUR DEVICE NAME *****
searchLine = 'received "Garage Sensor" sensor update to '
# **************************************************

# Look for Lux ---------------------
# Go backwards through log, newest to oldest
for logevent in reversed(log):   
   if re.search(searchLine + ".*lux", logevent):
      lux = logevent.split(" ")[7]
      indigo.server.log("  MS6: RegEx Lux found in eventLog: ["+lux+"]")
      # Load into the custom variable ****** UPDATE THIS PART ******
      indigo.variable.updateValue(96535918, value=lux)
      # Stop looking, we have the newest update, we dont want older ones
      break

for logevent in reversed(log):
   if re.search(searchLine + ".*%", logevent):
     humid = logevent.split(" ")[7]   # [69:72]
     indigo.server.log("  MS6: RegEx Humidity found in eventLog: ["+humid+"]")
     indigo.variable.updateValue(104851327, value=humid) # "ZWHumid"
     break

for logevent in reversed(log):
   if re.search(searchLine + ".*F", logevent):
     temp = logevent.split(" ")[7] # [69:73]
     indigo.server.log("  MS6: RegEx Temperature found in eventLog: ["+temp+"]")
     indigo.variable.updateValue(169923791, value=temp) # "ZWTemp"
     break

I then added another schedule to look for motion updates and have this running every 15 seconds:

Code: Select all

# Scan log for MultiSenor6 ZWave Updates
# Uses regular expressions
import re

# Number of log entires to go back through and scan
lines = 50

# Get the last xxx log entires
logEntries = indigo.server.getEventLogList(lineCount=lines)

# Split by newline so we can process the array from newest message to oldest
log=logEntries.splitlines()
logs = len(log)

# This is the common text that comes back for the mulitsensor 6
# ****** UPDATE THIS TO MATCH YOUR DEVICE NAME *****
searchLine = 'received "Garage Sensor" status update'
# **************************************************

# Go backwards through log, newest to oldest
for logevent in reversed(log):   
   if re.search(searchLine + ".*is on", logevent):
     indigo.variable.updateValue(103272203, value="true")
     # Stop looking, we have the newest update, we dont want older ones
     break

   if re.search(searchLine + ".*is off", logevent):
     indigo.variable.updateValue(103272203, value="false")
     break

It looks at fewer lines because we're looking so often and it changes a motion variable to true or false as appropriate.

Finally, I have a schedule looking for battery levels on the sensors running every hour:

Code: Select all

# Scan log for MultiSenor6 ZWave Updates

# Uses regular expressions
import re

# Number of log entires to go back through and scan
lines = 500

# Get the last xxx log entires
logEntries = indigo.server.getEventLogList(lineCount=lines)

# Split by newline so we can process the array from newest message to oldest
log=logEntries.splitlines()
logs = len(log)

# This is the common text that comes back for the mulitsensor 6
# ****** UPDATE THIS TO MATCH YOUR DEVICE NAME *****
searchLine = 'received "002 - Garage Sensor" status update '
# **************************************************

# Go backwards through log, newest to oldest
for logevent in reversed(log):   
   if re.search(searchLine + ".*battery level", logevent):
      battery = logevent.split(" ")[10]
      battery = battery[:-1]
      # indigo.server.log("  MS6: RegEx Battery found in eventLog: ["+battery+"]")
      indigo.variable.updateValue(1197983521, value=battery)
      # Stop looking, we have the newest update, we dont want older ones
      break

This enters the percent value in a battery variable that I watch to mark the battery as low when it reaches a certain level.

Very hack-y, but it is sure better than NO multi sensor support!

Looking forward to official support because even though I enjoy writing hacks, I don't like my system running on them.

Rick

I was wondering just the other day about plugin support for devices not yet supported, using this exact concept.

Plugins can't access the ZWave layer but they can do everything in this thread and maintain device states for them.


Sent from my iPhone using Tapatalk

Hi mikebnz,

Thanks for this script. Have you done anything special to get the multisensor to write to the log? I only get status updates about the battery level, nothing about the light level or temperature. It's powered with USB.
I'm currently trying to send raw z-wave commands to force it to report the sensor values but no luck for now.