bspranger / Xiaomi

my Xiaomi Device Handlers for Smartthings
Apache License 2.0
521 stars 1.36k forks source link

Xiaomi mijia Honeywell Fire Alarm Detector (circa 20€) #59

Closed foz333 closed 6 years ago

foz333 commented 6 years ago

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?

ronvandegraaf commented 6 years ago

A few days ago I also ordered two to test.

foz333 commented 6 years ago

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.

veeceeoh commented 6 years ago

It's a kind of sensor, right?

I say go for it.

foz333 commented 6 years ago

https://github.com/foz333/Xiaomi/blob/master/devicetypes/bspranger/xiaomi-mijia-honeywell-fire-detector.src/xiaomi-mijia-honeywell-fire-detector.groovy

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.

veeceeoh commented 6 years ago

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.

veeceeoh commented 6 years ago

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?

foz333 commented 6 years ago

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...

first logging

It' a noisy one to test. Had to move my hub into the garage to test so i sont wake the kids.

chnsawalex commented 6 years ago

Cover the speakers with tape for testing. That should help a bit.

foz333 commented 6 years ago

I have no idea how to cover the speaker... :(

fortunately the log was pretty helpful.

reporting all good now:

log2

and a little Screenshot: screenshot_2018-02-12-22-48-51 screenshot_2018-02-12-22-55-04 screenshot_2018-02-12-22-55-08

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.

foz333 commented 6 years ago

@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.

bspranger commented 6 years ago

@foz333 I thought I saw a error in your log about null

veeceeoh commented 6 years ago

@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")
}
ronvandegraaf commented 6 years ago

Running this DH now. Works great Foz333!

foz333 commented 6 years ago

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?

ronvandegraaf commented 6 years ago

Yeah, of course!

Would be really awesome if we could bring the 'reset', 'self check' and 'sensitivity' functions to this DH.

ronvandegraaf commented 6 years ago

I found this post with sniffer results: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/152#issuecomment-326820921 https://pastebin.com/59rUTJKv

foz333 commented 6 years ago

@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.

screenshot_2018-02-13-11-03-51

veeceeoh commented 6 years ago

@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.

foz333 commented 6 years ago

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

debuggered

foz333 commented 6 years ago

@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 image

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,

foz333 commented 6 years ago

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?

foz333 commented 6 years ago

// 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

veeceeoh commented 6 years ago

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.

bspranger commented 6 years ago

Implemented