meross_lan
meross_lan copied to clipboard
krahabb
Add support for Smoke Detector
Is your feature request related to a problem? Please describe. I‘ve connected a Smoke Detector to the Hub and the battery state is available as entity but unfortunately not the state from the Smoke Detector
Describe the solution you'd like Add entity for Smoke Detector state and if possible for high temperature as the Smoke Detector is also able to detect this
Hello @smartmatic , I would be happy to try but I need a diagnostic trace to start with.
Cool :-) Here are two diagnostics. One from the Hub and one from the smoke detector.
Well...it's a bit tricky since the only meaningful payload is:
"Appliance.Hub.Sensor.All",
{
"all": [
{
"id": "280000000A7F",
"online": {
"status": 1,
"lastActiveTime": 1649063189
},
"smokeAlarm": {
"status": 170,
"lmtime": 1649063189,
"interConn": 0
}
}
]
}
This carries some obvious and common info (like device id and online status) and the 'smokeAlarm' field which carries the smoke alarm state. Now, inside 'smokeAlarm', I don't get what 'status' is, nor I don't get 'interConn'.
It also appears this device exposes a kind of a toggle function: this is also unknown to me (maybe you can activate/deactivate the sensor?)
Right now I'm going to implement a bunch of 'plain' switch/sensors in order to interact and report the device state. If you'll be able to clone from the dev branch that would speed up testing else I could anyway publish a 'beta' release in order to ease the download process (no issue at all - just let me know)
I'll be back as soon as the dev code is available ;)
Right now I'm going to implement a bunch of 'plain' switch/sensors in order to interact and report the device state. If you'll be able to clone from the dev branch that would speed up testing else I could anyway publish a 'beta' release in order to ease the download process (no issue at all - just let me know)
What does that exactly mean? How can i do it?
I you like i can create a new diagnostic with a test alarm and hope that it contains more details.
Right now I'm going to implement a bunch of 'plain' switch/sensors in order to interact and report the device state. If you'll be able to clone from the dev branch that would speed up testing else I could anyway publish a 'beta' release in order to ease the download process (no issue at all - just let me know)
What does that exactly mean? How can i do it?
I you like i can create a new diagnostic with a test alarm and hope that it contains more details.
It involves using the command line git commands in order to download to your HA instance the 'dev' branch where I usually post incoming features before actually publishing them through a 'Release'. Since you asked I guess you're not very familiar with command line usage of git so no worries: I'll just publish it so you'll be able to automatically download through HACS advertised updates ;)
The trace with different states could be definitely helpful so we'll be able to eventually guess more on behaviours. As for the 'status' property I was talking before, since it reports 170 I was wondering if it represents a temperature in tenth of degrees (other meross sensors report temperatures with this scale) and that could be read as a '17° C', could it be the temperature the sensor is reading? I've seen by the manual it also contains a temperature sensor.
I've just published an 'alpha' in Releases so you should be able to download it and grab the trace with that. I've already added some features to better manage the smoke detector and tracing with this new release would help determining if the path is correct ;)
I've just published an 'alpha' in Releases so you should be able to download it and grab the trace with that. I've already added some features to better manage the smoke detector and tracing with this new release would help determining if the path is correct ;)
I've created a new debug trace activated diagnostic. Should be more helpful?
config_entry-meross_lan-85afbed8c566acb66c26e9cc1680bc96.json.txt
@krahabb I‘ve installed now version 2.5.8 I will send an additional debug trace with this release tomorrow. I can see the new enteties for the smoke detector
Here is another Trace with Integration version 2.5.8 During the trace i pushed the test button to simulate smoke detection and to test the device. I am not sure if this enough to show smoke alarm?
config_entry-meross_lan-85afbed8c566acb66c26e9cc1680bc96.json.txt
Well...I've discovered something but I can't figure out what to do next (we'll discuss this ;)
when the trace started (around 8:32 this morning) the sensor was reporting this timestamp as 'last sensor update' (the field is reported as 'lmtime' inside the protocol/trace):
- Friday, April 8, 2022 7:57:13 AM
This could be interpreted in many different ways but usually this is the last time the sensor device sent data to the hub. This could be because the sensor detected and raised an alarm (this could be obvious) but also because of another 'unsolicited' internal update from the sensor not really triggered by an alarm. I guess these sensors keep pushing internal state updates to the hub on a somewhat regular basis: they do so not so frequently to preserve the battery but still they have to do that in some way..at least this is the behaviour of the ms100 temp/humidity sensor I own. Think of the battery level too: the sensor will sometime send the battery level to the hub.
During the tracing, this 'last sensor update' was updated to:
- Friday, April 8, 2022 8:32:30 AM this is likely right after you 'pushed the test button' so it means this was reported to the hub and so it gets reflected to meross_lan but the problem is no other field was changed after this so we still have:
- 'status' = 170
- 'interConn' = 0
At this point, I really don't know whats next: I strongly suspect the 'status' field is reporting the alarm state but it didn't change during the trace, even during your test, so I could guess it only changes when an actual alarm is raised and not when you push the button. In order to refine the reasoning behind that I need to know what happened in the Meross app: did it report/notify you in some way of your test alarm raised? If it did then we're missing some other info but I suspect these would only be discovered when we connect to the hub over MQTT (we would then need to disconnect the hub from the Meross cloud and have it working in our MQTT environment).
Or, since meross_lan by default polls the device every 30 sec, the alarm was 'active' only in between and we missed the reading.
If this is the case, you could lessen the polling period in meross_lan device integration configuration or, let the alarm stay active for more than 30 seconds. Even better, simulate a real alarm (not by burning your house ;) by some way.
I see this is getting a bit troublesome, it would be nice if we could have some other testers around but since the device is pretty new we'll need some time though
P.S. The beta 2.5.8 provides you a 'switch' for the smoke detector. In the trace it is reported active (on). Could you see what happens when you turn it off in HA ? Do you see anything changing in the reported state for the smoke detector in the Meross app ? Maybe it works like an 'enable' switch for the whole sensor or for just a part of it ?
@krahabb I've done some further tests and and my house is not burning because i used a Test Spray :-)
Here is the result for a real smoke alarm
[ "2022/04/08 - 13:34:14", "RX", "http", "GETACK", "Appliance.Hub.Sensor.All", { "all": [ { "id": "280000000A7F", "online": { "status": 1, "lastActiveTime": 1649417629 }, "smokeAlarm": { "status": 25, "lmtime": 1649417629, "interConn": 1 } } ] } ],
So both states for the sensors changed. I guess InterConn shows a detected alarm as it turned from 0 to 1 Then status changed from 170 to 25.
config_entry-meross_lan-85afbed8c566acb66c26e9cc1680bc96.jso.txt
Furthermore i checked what happend when disabling the switch but I cant see any changes in the meross app. But functional wise it looks like the sensor is disabled as to that time the smoke sensor does not react after using the test spray. But maybe it was not enough? I will repeat this test to be sure that nothing will happen once the device is switched off.
Good job! The status going from 170 to 25 is very strange though...we can't figure out if that's a kind of signal level like the amount of smoke or non-smoke on the sensor or, if it carries some status codes about the type of alarm. If you could also try to overheat and see the reading we could better identify its behaviour since the device should also report overtemperature alarms Nonetheless this is very promising!
The interConn boolean is very likely representing the alarm state instead: 0 -> all good 1 -> alarm
Good job! The status going from 170 to 25 is very strange though...we can't figure out if that's a kind of signal level like the amount of smoke or non-smoke on the sensor or, if it carries some status codes about the type of alarm. If you could also try to overheat and see the reading we could better identify its behaviour since the device should also report overtemperature alarms Nonetheless this is very promising!
The interConn boolean is very likely representing the alarm state instead: 0 -> all good 1 -> alarm
I tried to test overheating near my oven but it doesn't work. Currently i have no idea how to test it in order to provide this information?
@krahabb I've started a new test to simulate heat and it has worked. Here ist the log config_entry-meross_lan-85afbed8c566acb66c26e9cc1680bc96.json.txt
[ "2022/04/10 - 19:02:08", "RX", "http", "GETACK", "Appliance.Hub.Sensor.All", { "all": [ { "id": "280000000A7F", "online": { "status": 1, "lastActiveTime": 1649610120 }, "smokeAlarm": { "status": 24, "lmtime": 1649610120, "interConn": 1 } } ] } ],
My assumption: state 24: Heat alarm Interconn 1: Alarm
[ "2022/04/10 - 19:03:38", "RX", "http", "GETACK", "Appliance.Hub.Sensor.All", { "all": [ { "id": "280000000A7F", "online": { "status": 1, "lastActiveTime": 1649610120 }, "smokeAlarm": { "status": 26, "lmtime": 1649610120, "interConn": 0 } } ] } ],
After it was recognized i turned off the alarm via the button on the smoke dectector and told the meross app it was a wrong alarm
But after i've done that the smoke detector takes a while until the state changes in app to no alarm. Looks like the state changes first after the smoke detector has cooled down.
My assumption: Interconn 0: No alarm state 26: Sensor still hot but alarm turned of manually
Hope that helps to make a step forward?!
Yes definitely, I'll review the code/behaviour after these new findings. I'm actually away so I cannot work on it right away but I'll soon get back at coding! Thank you!
Aww..yep..sorry!!! I fell apart with 'some business' and didn't care too much on meross_lan lately. At any rate, I was a bit halted on progress anyway since the information we collected are not definitive in my opinion. The codes you see and your explanations are ok but they look very very strange. I couldn't detect any 'logical' meaning for those values put in 'state' and it would be a bit 'rude' to just plain map them. You could say: this is what we have so far but then I would hardcode into meross_lan some logic which, as I said, doesn't make a great sense. Also, I thought that the same behaviour (matching the state value to a 'known' alarm state) could easily be done in automation: they would just be a bit cryptic but the behaviour would be the same: in the end you would use a check against a numeric 'state' property instead of a check against an alphanumeric string representig the alarm.
Let me know what would you expect as a 'reasonable and simple behaviour' for this kind of sensor. At the time, the binary value in interConn already looks like an alarm on/off state indicator.
Some additional info for sensor state:
| status | status (muted) | meaning |
|---|---|---|
| 17 | 20 | temperature sensor error |
| 18 | 21 | smoke sensor error |
| 19 | 22 | battery error |
| 23 | - | test alarm |
| 24 | 26 | high temperature alarm |
| 25 | 27 | smoke alarm |
| 170 | - | default (no alarm/no error) |
If an alarm/error is muted by pressing the device's button, the state first changes to the muted one and after a cool down time the device will check if the cause of the alarm is still present. If yes, alarm will be unmuted again and state switches back to the corresponding unmuted alarm state, otherwise state returns to default.
"interConn" seems more like an "interaction required" flag, but since every alarm requires an interaction... the meaning should be the same.
