Closed foz333 closed 6 years ago
A few days ago I also ordered two to test.
Device arrived this morning... Good looking thing. Decided to pretty much start a new DH for this, gonna 'borrow' a lot from your existing DHs to keep the DH family all off the same feature/base code. Should be able to get a beta out some point this week. Assuming you guys want this in the family... I know it's not exactly a conventional switch for the set? Just say if it's not a fit and I'll move it out.
It's a kind of sensor, right?
I say go for it.
Started, working with basic functionality... i've tried to use the most up-to-date versions of setting to keep things homogeneous.
Battery may be a pain, was hoping this would work with same code as other Xiaomi devices. ... need to give it a bit of time to see whats going on but had a decent first crack at it.
So have you tried testing it with actual smoke?
It's interesting that this device uses the ZigBee IAS (Intruder Alarm Systems) messaging protocol, because none of the other sensors use it.
As for the battery, if you're logging the full hexadecimal catchall
: and read attr - raw:
messages, I can help decipher those. If it's sending IAS Zone messages, there's a chance it may actually use the ZHA standard method of battery reporting.
I just looked at the existing DH created by Kenneth Evers, and can see in his log output screenshot that the smoke detector reports battery voltage in exactly the same way as all the other Xiaomi sensors - in a catchall:
message. The first two bytes 01FF, are the same, and the battery voltage are in byte numbers 7 & 8, which are 990C. Reverse those (because they are big-endian) to 0C99, which is equal to integer 3225, divide by 1000 and the voltage is 3.225V.
So your DH code should reveal the battery voltage just fine. I'd like to know if it reports about every hour like other sensors. Also - what kind of battery is it?
With actual smoke yes, 5 matches set it off, and damn its loud. Unfortunately i'm not getting this in application yet, the device itself is independant will alram without a hub.
The battery is a CR123a ... which i have never seen before (but they estimate 5 years on that)
first look at logging to see whats going wrong as i've clearly messed up the passing of info somewhere...
It' a noisy one to test. Had to move my hub into the garage to test so i sont wake the kids.
Cover the speakers with tape for testing. That should help a bit.
I have no idea how to cover the speaker... :(
fortunately the log was pretty helpful.
reporting all good now:
and a little Screenshot:
So, i'll double check real smoke tomorrow... but that's the basics in now.
Happily the button, at a minimum forced a battery update, and uses IAS test.
I sleep now and try to check more functions tomorrow.
@veeceeoh just occurred to me last tile was blanck as there is no default date for battery. I just go into configuration and flick this. I guess this will be same for other DHs you have worked on... have you checked this on a newl'y added device. I guess a little line in the installed def would sort this out.
@foz333 I thought I saw a error in your log about null
@foz333 - Excellent work on this new DTH!
Yes, I put code both into installed()
and configure()
so the battery changed date gets set when a device is paired:
// configure() runs after installed() when a sensor is paired
def configure() {
log.debug "${device.displayName}: configuring"
state.battery = 0
if (!batteryRuntime) resetBatteryRuntime(true)
checkIntervalEvent("configured")
return
}
// installed() runs just after a sensor is paired using the "Add a Thing" method in the SmartThings mobile app
def installed() {
state.battery = 0
if (!batteryRuntime) resetBatteryRuntime(true)
checkIntervalEvent("installed")
}
Running this DH now. Works great Foz333!
Great glad you have your devices, hopefully you can help me with some test and debugging, When i'm not at work and can play with these my kids are asleep. As i'm sure you have found out, these are extremely noisy. As @bspranger pointed out there are still some parsing errors generated by randomly pressing buttons at certain times for certain durations that need ironed out. A lot of test cases to go through.
At some point in future if anybody has a CC2531 USB Dongle or a MI Hubthere are some interesting features we may ba able to bring over... a dongle/sniffer might let us see to send to activate the smoke detector. Apparently they can be paried so must should be possible to trigger remotely?
Yeah, of course!
Would be really awesome if we could bring the 'reset', 'self check' and 'sensitivity' functions to this DH.
I found this post with sniffer results: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/152#issuecomment-326820921 https://pastebin.com/59rUTJKv
@veeceeoh i think you asked about battery scehule for this device. It is the same as the other Xiaomi sensors... around the 45-55min mark. It is pretty regular.
@foz333 - What you want to look at from the forum thread that @ronvandegraaf linked to is this Excel Spreadsheet.
I think it has everything needed to access the capabilities of the detector.
Fortunately, only endpoint 01 is used on all cluster/attributes listed, which means SmartThings should be able to send commands, using zigbee.Command(0xXXXX, 0xYYYY)
XXXX being cluster, and YYYY the attribute.
that's what i was hoping when i saw the spreadsheet
i've got rid of my error and basic functions are there so ive put in a pull to get the thing to genpop and hopefully get some more test subjects
@veeceeoh help please (request not soley restricted to kieth)
i started to try and integrate the zigbee.command but i'm clearly missing something. Can you give me a little nudge in the right direction.
basically i added a couple tiles i press one and i call this
zigbee.Command(0x0500, 0x23, "0x03010000")
my error says as below (i read this as the 1st 2 parameters should be objects not integers)...
21:08:39: error groovy.lang.MissingMethodException: No signature of method: physicalgraph.zigbee.Zigbee.Command() is applicable for argument types: (java.lang.Integer, java.lang.Integer, java.lang.String) values: [1280, 35, 0x03010000] Possible solutions: command(java.lang.Object, java.lang.Object, java.lang.String), command(java.lang.Object, java.lang.Object, [Ljava.lang.String;), command(java.lang.Object, java.lang.Object, java.lang.String, java.util.Map) @line 297 (resetSmoke)
ok... but the ref doc (http://docs.smartthings.com/en/latest/ref-docs/zigbee-ref.html) says zigbee.command(Integer Cluster, Integer Command, [String... payload])
sooo i'm feeling lost
here is the spreadsheet for reference
any chance you can give me a few different combos to chuck in and see what comes out. i have a feeling i'm going to keep getting the same errors if i persist on my current path
thanks to anyone for any guidance here,
okay... so error is a simple one... screwed up case... lower case 'c' in command not upper
using...
0xXXXX, 0xYYYY XXXX being cluster, and YYYY the attribute.
so i try zigbee.command(0x0500, 0xFFF1, "0x03010000") no output
i see this in the log when i push the phsical button ... Parsing read attr: cluster: 0000, attrId: 0005, value: 6C756D692E73656E736F725F736D6F6B65
so i thought lets try that... zigbee.command(0x0000, 0x0005, "6C756D692E73656E736F725F736D6F6B65")
that at least forces a debug in the log
21:47:59: debug SmartShield(clusterId: 0x0000, command: 0x0b, data: [0x05, 0x81], destinationEndpoint: 0x01, direction: 0x01, isClusterSpecific: false, isManufacturerSpecific: false, manufacturerId: 0x0000, messageType: 0x00, number: null, options: 0x0140, profileId: 0x0104, senderShortId: 0x30e4, sourceEndpoint: 0x01, text: null)
21:47:59: debug Xiaomi Honeywell Smoke Detector: Parsing description: catchall: 0104 0000 01 01 0140 00 30E4 00 00 0000 0B 01 0581
@ronvandegraaf you started to play with yours at all?
anybody any ideas as to a good command or set of commands to try based on the spreadsheet in previous post?
// zigbee.command(0x0500, 0xFFF1, "0x03010000") // Test initiated from gateway... no logs // zigbee.command(0x0000, 0x0005, "6C756D692E73656E736F725F736D6F6B65")... catchall: 0104 0000 01 01 0140 00 30E4 00 00 0000 0B 01 0581 // zigbee.command(0x0500, 0xFFF1, "0x0000FF000002") // button pressed... no logs // zigbee.command(0x0500, 0xFFF1, "0x0000FF000000") // button released... no logs // zigbee.command(0x0500, 0xFFF1, "0x04020000") // Set request: little smoke... no logs
i expected the debug to pickup something on the 0x500 cluster command, but nothing
I haven't actually worked with zigbee.command(), but I'll do a bit of research.
By the way, 6C756D692E73656E736F725F736D6F6B65
is just the name of the sensor, "lumi.sensor_smoke", so that wouldn't work as a command.
Implemented
I'm going to ordered one of these: https://www.gearbest.com/alarm-systems/pp_615081.html
There is an existing DH: https://community.smartthings.com/t/release-beta-xiaomi-honeywell-zigbee-smoke-detector/94790
Looks like they already got the important fonctionnalité... but the thread never had a big audience so full potential never reached.
It's probaby not complaint with our insurance (not CE or american equiv so keep a stupid one near by)... but i'd rather have this in the house and send me a text if im not in than the stupid one alert nobody and burn my property to the ground... as with xiaomi its hella lot cheaper than nest so, one in garage, lounge etc. Anyway i think this would be a good addition to your growing xiaomi DH family.
GB normally takes like a month to deliver stuff to me so, i'll maybe have a bit more to say in a while.
Have any of you got one of these already... thoughts impressions?