Great, the more people they get the request from the better!
3 Likes
Some progress… I’ve heard from one of the Boundary team and got some of the Z-Wave details for the siren and sensors which I’ll share once I’ve tried it out myself.
@Mariano_Colmenarejo could I ask if you could add the fingerprint of the Siren in to your Z-Wave Siren Mc edge driver please?
Siren
Manufacturer ID: 0x044a; Product Type: 0x0004; Product ID: 0x0002
Capabilities: siren, strobe, tamper alert, battery, temperature
Hi @sipuncher
Added to this driver version
───────────────────────────────────────────────────
Name Z-Wave Siren Mc
Version 2023-03-23T11:55:14.635827036
───────────────────────────────────────────────────
- id: "Boundary Siren"
deviceLabel: Boundary Siren
manufacturerId: 0x044A
productType: 0x0004
productId: 0x0002
deviceProfileName: alarm-battery-temp-tamper
2 Likes
Amazing, thank you.
I’ve got all of the Z-Wave parameters from Boundary now and details for how the devices are meant to work. Rather than me keep asking you for changes, is your code on Github that I could propose PRs to? I don’t know how the drivers are structured to allow for device specific features such as this.
It’s not published on github, but it’s a copy of the stock Z-wave Siren to which I’ve added devices and profiles.
You can use the stock driver as a base just like me.
For your siren I create a new profile “alarm-battery-temp-tamper” and add the fingerprints to the multifunctional-siren subdriver and fingerprint.yml file
name: alarm-battery-temp-tamper
components:
- id: main
capabilities:
- id: alarm
version: 1
config:
values:
- key: "alarm.value"
enabledValues:
- 'off'
- both
- key: "{{enumCommands}}"
enabledValues:
- 'off'
- both
- id: switch
version: 1
- id: temperatureMeasurement
version: 1
- id: battery
version: 1
- id: tamperAlert
version: 1
categories:
- name: Siren
and add the fingerprints to the multifunctional-siren subdriver and to fingerprint.yml file
local MULTIFUNCTIONAL_SIREN_FINGERPRINTS = {
{ manufacturerId = 0x027A, productType = 0x000C, productId = 0x0003 }, -- Zooz S2 Multisiren ZSE19
{ manufacturerId = 0x0060, productType = 0x000C, productId = 0x0003 }, -- Everspring Indoor Voice Siren
{ manufacturerId = 0x0403, productType = 0x0003, productId = 0x0000 }, -- Abus siren
{ manufacturerId = 0x0206, productType = 0x8009, productId = 0x1000 }, -- Heiman HEIEHS2W siren
{ manufacturerId = 0x044A, productType = 0x0004, productId = 0x0002 } -- Boundary Siren
}
and to fingerprint.yml file
- id: "Boundary Siren"
deviceLabel: Boundary Siren
manufacturerId: 0x044A
productType: 0x0004
productId: 0x0002
deviceProfileName: alarm-battery-temp-tamper
1 Like
Very helpful thanks - I’m up and running! What sub-driver did you use for the motion-battery-tamper and contact-battery-tamperalert-temperature drivers above, so I can base mine from the same starting point?
Hi @sipuncher
These devices do not need a subdriver, they work with the default handlers.
They just need to add the fingerprints to the fingerprints.yml file
- id: 044A/0004/0003
deviceLabel: Boundary Motion Sensor
manufacturerId: 0x044A
productType: 0x0004
productId: 0x0003
deviceProfileName: motion-battery-tamper
- id: 044A/0004/0007
deviceLabel: Boundary Contact Sensor
manufacturerId: 0x044A
productType: 0x0004
productId: 0x0007
deviceProfileName: contact-battery-tamperalert-temperature
Ah ok, so the following line in the init.lua file tells SmartThings to use the default implementation of those capabilities? I then only need to write a sub-driver for any additional capabilities I want to add?
defaults.register_for_default_handlers(driver_template, driver_template.supported_capabilities)
The first thing you need is to download the lua default 47.x libraries
In those libraries, for zwave and zigbee are the default capability handlers that the hub firmware currently has.
If the capability you want to add has defaults defined in the libraries, then you just need to add the capability to the profile and make sure it is also defined in the driver template in the supported capabilities table.
1 Like
The subdrivers are necessary when you need to manage some capability, command class or zigbee attribute or cluster manually.
Also if you need to handle some specific code in a life cycle, doConfigure, added, init… for a certain devices, without affecting the other devices in the driver.
You have several examples if you analyze the subdrivers in stock drivers and how they are built.
The can_handle function determines which devices will execute the subdriver code instead the defaults.
Thanks for the advice. I’ve got a basic driver working now that covers the motion sensor, contact sensor and siren. I’ve just added in the preferences parameters for each but it’s been good to get my first driver working and gives me a platform to add in the custom features for Boundary.
2 Likes
I just happened upon this thread so thought I would clear up a few things…
I am the same Phil mentioned above, ex-head of customer experience at Boundary. Before I say any more though please note the following:
I cannot provide 121 support for any part of the Boundary system. I’ve had numerous requests reaching out for support over the last few months and I am very limited in what I can/cannot say or do to help. I was made redundant from Boundary just before Christmas and I have no access to any of the internal systems, just what I have in my head 
Now…
The sensors do operate on a Zwave 700 series and do expose multiple parameters including the LED light. The problem is I can’t detail which parameter does what as I don’t have access to that detail.
The sensors are not tied to the hub directly, if you were to factory reset the hub and the sensor then you could join any Zwave network. I have done exactly this using an Aeotec 7 stick plugged into my Home assistant NUC. I’ve not bothered with the Smartthings route as I already had heavily invested in HA.
It does sound as though there is a method on ST to save the sensors which is good to hear.
I’m sorry I can’t help more and I will answer any questions, just be aware that I might not be able to give a full and frank reply!
4 Likes
Hi Phil, good to hear from you.
Paul Walton got in touch with me and has shared the Z-Wave parameters for each device and I’m in the process of building upon the stock SmartThings Drivers for Z-Wave sensors and siren to support all of the Boundary features.
4 Likes
Good on Boundary for providing you the details!
2 Likes
Nice. If I can help at all let me know.
3 Likes
If anyone wants to use their Boundary siren and sensors with SmartThings I have a working driver now under this channel (thanks to @Mariano_Colmenarejo for the advice):
There is a single driver that covers all of the devices (Siren, Contact Sensors, Motion Sensors). It’s working well for me for the past few days, but obviously use at your own risk.
Current limitations:
- Tamper notifications on motion and contact sensors seem to be a bit erratic
1 Like
Hi @sipuncher
I see that the parameter table posted is missing a very important argument, the size in bytes of the value.
If the size you send doesn’t match the size the device expects, you won’t see an error in the CLI, but it won’t be accepted by the device.
To know the size of each parameter you can use the Z-Wave Device Config Mc driver and do a scan of all the parameters and it will give you the current value and the size.
Also, if for a parameter that has a value with a range of 0 to 255 (0x00 to 0xFF) and the size is 1 Byte, if you try to send a value greater than 127 the default libraries will give an overflow error and not send the value.
This is because for the default libraries the expected ranges are -127 to 127 instead of 0 to 255.
In the most modern devices the size has doubled:
- to send values from -127 to 127 use a size of 1 bytes
- to send values from -32767 to 32767 use a size of 2 bytes
- to send values from -2147483647 to 2147483647 use a size of 4 bytes
If you see that the device uses sizes that are not in these ranges then you have to send the 2’s complement, for values greater than half plus one to have not the overflow error.
I use this code for the preferences of some old fibaro devices with this problem.
2 Likes
That’s helpful to know, but I don’t think that’s the issue here… I have used your driver to discover the parameter sizes, and they seem to have used 4 bytes for them all which is how I’ve setup the driver.
I’m sure it’s just a silly issue in the code, but it takes so long to debug as they wake up so infrequently!
1 Like
@Phil_Williams a pleasure to see you on here, you helped me regularly with lots of little issues, iv unfortunately been where you are at that same time of year and its awful, I hope your well seeing as we had a mutual friend.
@sipuncher I deeply appreciate all this work you have gathered and of course to all the others who have helped. I unfortunately am a non coder so im helpless in this regard. Oddly though my system is scrapping along with use, theres a few bugs occurring though, I did however when I got the system connect it to my Aeotec V3 hub so all my sensors, extender, hub and siren are connected.
I am going to bed hoping it something does not set off the siren then I can not turn it back off due to not having ladders.
My other observation in all this has been the following: “The sensors are not tied to the hub directly, if you were to factory reset the hub and the sensor then you could join any Zwave network. I have done exactly this using an Aeotec 7 stick plugged into my Home assistant NUC. I’ve not bothered with the Smartthings route as I already had heavily invested in HA.”
Does this mean if regardless if I pushed the sensors into HA or used the driver created for ST that the control hub is useless, just curious what the deal is with that as that contained a lot of features to troubleshoot, and also for other people in a household moving about in the morning if the alarm is part armed it would trigger the countdown to deactivate so if the hub is useless then you no longer get pre warning that the sensors might set the alarm off after the 1 minute count down. These features still seem to be working for me and for the likes of a security system having it part arm give you that security while one is asleep but then when one wakes thats forgot its armed or is not connected to the system say for example a guest or non technical persons then what happens.
Apologies as its a bit of a rabble on my part but I am in the same camp as you Simon, that I really don’t want to see any of this go to waste but I need to know whats going to be possible moving forward if I stick with it sort of working? atm. If I use this driver as is what I and users can use or set up? Or if you hope as you mentioned above to hopefully just build a fully open source security system?
I have also emailed the liquidator so I will do what I can on my end, if though they could pop the open source files to a community. What do you think could be achieved are we looking a potential goldmine opportunity to bring back a lot of the pain features but ran locally or via a community cloud?
The other thing to ask is if people feel its a bust for them would it not be good to inform people where they could donate or sell the equipment for those who would want more sensors, hubs and sirens?
Then finally would it be an easy pick for what people should use going forwards? I recall I done an exhaustive research and I picked Boundary for multiple reasons but the others of note was Simplisafe, abode and possibly ADT. @Phil_Williams possibly something use had lots of insight to gaging competition? I had got my Boundary system to be fitted to my first house and its rather a sad moment to face having to start all over and have to bounce back to the other choices of which most are not UK brands.
Thank you for entertaining all my ramblings as its been stiring for months and only just came across this thread.
Scott
Hi Scott,
I don’t know how long Boundary’s cloud will remain operational, but I suspect not much longer as there is no one to pay the bill, or maintain it. I was seeing a bunch of issues so decided to investigate moving the sensors to SmartThings as I’ve had a hub and other Z wave devices for several years.
I think you should be ok arming and disarming your system from the keypad regardless, so hopefully your scenario of a siren you can’t disable doesn’t materialise!
To answer your question, yes the Boundary hub serves no purpose nor can be integrated with SmartThings/HA/Hubitat. The sensors and siren talk to the hub via Z Wave so these platforms are providing their own hub and cloud services. SmartThings has a home alarm function within it which works pretty well, with a partial arm option too. You are forced to do everything via the app, and have no beeping keypad warning, but can recreate that via other means. I think HA has an even richer alarm capability from another open source project.
The question will be if you have an existing platform to integrate with, how willing you are to customise to get something you are happy with. You could cut your losses and move to another packaged solution like Ring alternatively. I wanted to get the most from my Boundary investment and am pretty happy with what I have working now with SmartThings, with the added bonus of saving the £4 a month.