Closed MasterFeige closed 11 months ago
converter looks good, whats not working?
Thanks for your reply, this script works fine. I want to know, what do I need to do so that consumers can add this product to their home assistant tool and use it directly when they purchase it?looking forward to your answer, thank you very much.
I can add it but can you explain me the presence_time
and dis_current
options?
‘presence_time’ means how long the sensor continues to detect a signal before it is considered someone is present. 'dis_current' (distance_current)means the distance at which the sensor currently detects people.
thanks, added!
Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)
I think you can solve the problem by replacing "presence_delay" in the script with "keep_time".
------------------ 原始邮件 ------------------ 发件人: @.>; 发送时间: 2023年11月2日(星期四) 下午4:01 收件人: @.>; 抄送: "feige @.>; @.>; 主题: Re: [Koenkk/zigbee2mqtt] [New device support]: TS0601,[_TZE204_mhxn2jso] (Issue #18963)
Should this work OK? I copied the code from release into an external converter and when I try to alter any parameters in MQTT I get a message "missing converter".
The HA isn't even showing most of those parameters, and the luminance cannot be used as condition (only allows detection distance and presence).
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
Thank you, I ended up upgrading to the latest docker image so I don't have to keep loads on external converters (I had others too) but that caused a few other things to break (and this one didn't work regardless) so I raised a couple of issues.
Got everything connected using the latest version of m2q and HA. I've been testing a couple of these units for a while, but they just behave erratically and no amount of fine tuning seems to help.
@MasterFeige how does the min/max distance supposed to work? I assume it should affect "presence state" i.e. if the detection distance is not between the set min range and max range the "presence state" should still stay 0/none? I have those set at 50-350, yet half the time presence state changed without any detection distance at all (equal to 0) and sometimes I get some detection distance value like 224 yet the presence state stays at none.
Also, what do the "sensitivity" and "detection delay" do? They don't seem to make any effect whatsoever for me. In fact most of the parameters don't seem to make any difference no matter what I set them to, only the "keep time" seems to work, but the actual minimum delay appears to be around 10 seconds (even though my value is = 5).
Hi I wrote a quirk for this device on ZHA (I use both flavours of zigbee on my HA yellow). I see the data points are the same. So this should work. I can't get the built in converter to work, which I thought was this one. It is not, this one uses units of 1 second. The built in version used tenths of a second. It should be noted that not all devices that share model and manufacturer are the same these days. So it was probably great for the guy that wrote in built version.
I can tell you about function of the device when it works, I'm on safer ground ;)
Presence delay, effects function.> Below 65 seconds and the device only looks for large movements. 65 seconds and above and it detects breathing within the central detection cone.
current distance is only reported with any acuracy, within the central detection cone. I've never known the device to report a current distance value and not trigger. Unless outside the min max distance, or if you have a presence delay above one second. Note min and max detection distance function usually doesn't work (see below).
detection delay, how long it detects you before reporting your presence, can't be below 1 second, or with decimal point, as this can make the device crash. It only seems to accept full seconds
All distance are expected and reported back in full centermeteres. All times likewise in complete seconds. For the device I worked on, otherwise things broke.
Min and Max detection distance, don't work correctly for this device (for me) even in Tuya. This is not in an HA integration, but with the device attached to a proper Tuya gateway (that's how I get data points etc via their developer portal) so I think the firmware is broken.
Sensitivity This goes from 10 (least sensitive) to 0 (most sensitive). I use 3-4, if I have the presence delay at 65 seconds or above. And 1-3 for below 65 seconds
Hope this helps. I'm going to try my hand at installing this file, it looks great, and a good starting point for a noob of a few months like me.
Presence delay, effects function.> Below 65 seconds and the device only looks for large movements. 65 seconds and above and it detects breathing within the central detection cone.
Thank you, that is so weird! What does the sensitivity do then?
I've updated my original reply with the missing information
I forgot to mention that: Runs from 0 to 10 0 maximum sensitivity 10 Blind as a bat
In breath mode I use 3-4 Otherwise I use 1-3
I just noticed the code at the top of the page you commented on uses the correct full seconds and centermeteres. Unlike the version zigbee2mqtt is making me use. So no editing needed. Just need to find out how to use the file. Can you point me in the right direction please?
On Wed, 6 Dec 2023, 16:37 roastcom, @.***> wrote:
Presence delay, effects function.> Below 65 seconds and the device only looks for large movements. 65 seconds and above and it detects breathing within the central detection cone.
Thank you, that is so weird! What does the sensitivity do then?
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1843131529, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCSBBQPRGVADRDEIF4TYICGMTAVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGEZTCNJSHE . You are receiving this because you commented.Message ID: @.***>
Just need to find out how to use the file.
If you mean how to run the manual decoder then easy: In z2m config folder create a file with ".js" extension, copy the contents into that file, and in the configuration.yaml (z2m) add
external_converters:
- filename.js
After that restart z2m and it will start using the external converter from that point.
That is at least if you run everything in docker like I do, if you use HASSOS and m2q as a plugin, then I'm not quite sure. But they probably have that described in the manuals somewhere. The main idea is that you want to run an external converter for that device.
Thank you, sounds refreshingly easy
On Wed, 6 Dec 2023, 17:41 roastcom, @.***> wrote:
Just need to find out how to use the file.
If you mean how to run the manual decoder then easy: In z2m config folder create a file with ".js" extension, copy the contents into that file, and in the configuration.yaml (z2m) add
external_converters:
- filename.js
After that restart z2m and it will start using the external converter from that point.
That is at least if you run everything in docker like I do, if you use HASSOS and m2q as a plugin, then I'm not quite sure. But they probably have that described in the manuals somewhere. The main idea is that you want to run an external converter for that device.
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1843266065, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCUF7ESIIICPYXTCJ73YICN4RAVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBTGI3DMMBWGU . You are receiving this because you commented.Message ID: @.***>
I am yet to test it on a Tuya hub (probably won't even bother to be honest) but the behaviour on z2m is definitely different for me. I think the overall issue is that the detecting hardware/firmware is just unreliable, which in the end causes all sorts of issues.
First, all entities and settings are more or less properly supported (both in z2m and HA), which isn't a big surprise.
The min/max distance definitely works for me most of the time - it affect the presence state value, if the detection distance is not in the given interval the presence state doesn't change. The problem for me is that I saw 'presence' switched on 0m detections when I had 50m as min, and more often I saw detections at a distance within the interval but presence didn't change.
The detection delay - a bit murky that one. I suspect it's the one responsible for those unregistered detections above. The device seems a bit more 'responsive' at 0 and less responsive as the value increases. My guess is that is for how long the motion should be detected before the presence state changes. It doesn't seem like a linear dependency, but less is less and more is more.
Keep time - definitely affect the length of time the detected presence state lasts. Again, doesn't seem like a 1-to-1 relationship, but close within 5-10 sec. Minimum is 5 and at that value some of devices (I have a few) switch the presence off almost immediately, others at around 10 sec.
Illuminance - raw value (not in lux), I have a luminosity meter but honestly never bothered to verify the readings, they do seem fairly consistent though from what I've seen.
Detection distance - distance at which motion is detected, preeetty approximate, +- maybe 70cm or so. Also in all the time I wasted spent on these devices I've only seen several specific distances being reported with a step of exactly 56cm. I.e. I've seen 56cm, 112cm, 168cm but I've never seen anything in between. Whatever measures the distance cuts some serious corners.
It works ok-ish if it's right in front of you, like if you have it, idk, sitting on your desk to dim room lights when you're working, that might be ok, or if you wanna make sure a rat doesn't crawl through a vent (although I'm not quite sure it would pick up a rat). Under realistic conditions detections are pretty unreliable, and drop to near zero in the dark for some reason. I have no clue why, all of mine just turn near blind in the dark.
Hi, that sucks.
I wonder if we have the same format (mine are long thin angled rectangles, good for fitting in corners, not round, as shown in 2M). I have multiple manufacturers and they work the same way. My devices are totally reliable for detection. But that's under ZHA using my own quirk. Everything works reliably except min max value, which is erratic. But luckily I don't need that to be reliable. Maybe the erratic nature is just the inaccuracy you speak of.
It does need a presence delay (not detection delay) of over 65 seconds, so that it detects me sleeping on the couch though. But that's also in the instructions (on the one device that had instructions) as how to get breathing / micro detection working.
Detection delay, is accurate and repeatable on the devices I use in ZHA. I'm sure they will be on 2M also, once I load up the converter on this page. As it will only need minor changes for one device.
Interestingly the manufacturer version named on this page does not support the presence countdown data point according to Tuya development platform.
The other manufacturer version of the same rectangular format, reports the presence countdown, and it is 100% accurate.You can see you get exactly what you set in presence delay. Very handy.
I think you mentioned presence delay is not accurate on this version, but I may be confused. If that is what you said, that's disappointing. I wonder if that indicates an issue with this version? Thanks for the heads up.
I'm still using the inbuilt converter from zigbee2mqtt for this version though, and frankly the sensor doesnt work well enough for me to judge if anything works as intended. It crashes my device repeatedly, but then it is also being fed 10ths of seconds, not seconds, and the distance is setable by 1cm, not 50cm. This screws the versions I own.
It should be noted that the picture for the device in 2M shows a round device, mounted on a short stalk, which is a different format to mine, so maybe the wrong converter is loading. It recognised my device model and manufacturer correctly though, so it's odd it's shows, and links to a different physical model.
I hope the converter version on this page will work better. It is very close to what I would expect, but I'm new to 2M, so don't read anything into that.
As you say the lux reading (the only thing that works reliably) appears to be presented as a raw value, not calculated by the converter to a lux value, another frustration for me.
Thanks for filling me in.
On Thu, 7 Dec 2023, 15:32 roastcom, @.***> wrote:
I am yet to test it on a Tuya hub (probably won't even bother to be honest) but the behaviour on z2m is definitely different for me. I think the overall issue is that the detecting hardware/firmware is just unreliable, which in the end causes all sorts of issues.
First, all entities and settings are more or less properly supported (both in z2m and HA), which isn't a big surprise.
The min/max distance definitely works for me most of the time - it affect the presence state value, if the detection distance is not in the given interval the presence state doesn't change. The problem for me is that I saw 'presence' switched on 0m detections when I had 50m as min, and more often I saw detections at a distance within the interval but presence didn't change.
The detection delay - a bit murky that one. I suspect it's the one responsible for those unregistered detections above. The device seems a bit more 'responsive' at 0 and less responsive as the value increases. My guess is that is for how long the motion should be detected before the presence state changes. It doesn't seem like a linear dependency, but less is less and more is more.
Keep time - definitely affect the length of time the detected presence state lasts. Again, doesn't seem like a 1-to-1 relationship, but close within 5-10 sec. Minimum is 5 and at that value some of devices (I have a few) switch the presence off almost immediately, others at around 10 sec.
Illuminance - raw value (not in lux), I have a luminosity meter but honestly never bothered to verify the readings, they do seem fairly consistent though from what I've seen.
Detection distance - distance at which motion is detected, preeetty approximate, +- maybe 70cm or so. Also in all the time I wasted spent on these devices I've only seen several specific distances being reported with a step of exactly 56cm. I.e. I've seen 56cm, 112cm, 168cm but I've never seen anything in between. Whatever measures the distance cuts some serious corners.
It works ok-ish if it's right in front of you, like if you have it, idk, sitting on your desk to dim room lights when you're working, that might be ok, or if you wanna make sure a rat doesn't crawl through a vent (although I'm not quite sure it would pick up a rat). Under realistic conditions detections are pretty unreliable, and drop to near zero in the dark for some reason. I have no clue why, all of mine just turn near blind in the dark.
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1845447914, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCUIORKJFILZXDFDKZTYIHHQHAVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBVGQ2DOOJRGQ . You are receiving this because you commented.Message ID: @.***>
From what I've seen m2q rarely has correct pictures of niche devices.
The ones I have are these:
https://www.aliexpress.com/item/1005005590094557.html
I know you have high hopes for this converter, but the way it works in m2q is the external converter is released first and later it's just committed into the 'master branch'. You can look up the actual code here, it's nearly identical to this converter (as it should be) https://github.com/Koenkk/zigbee-herdsman-converters/commit/54ffe76c8e6ad6d22c402d16b525cd4d273d3c0d
I am surprised though that you say the device works well in ZHA (perhaps you have a different make?). From what I've surmised it's really the device that seems to be the issue - not the drivers. I've abandoned ZHA early on back when it was noticeably lagging in device support (and because it also seemed much easier for me to make a custom converted in z2m by myself), but maybe I should give it another try...
That's the correct device, but the control numbers generated by the ui on my HA yellow install, do not appear to comply with the settings of the code at the top of this page. Which is unfortunate.
I would not expect the device to work correctly if fed the numbers generated by the UI that I'm having to use 🤦♂️
My dark humour side is leaning towards an AI conspiracy 😐
You are correct it is easier to generate a converter than a quirk for sure, looking at the coding. Although like anything, the second one is easier.
Im relatively new to this HA game, I came from Samsung Smartthings two or three months ago. I love the freedom HA gives me
I have no preference over ZHA or 2M though, both are installed and working well on my HA yellow. In fact I have two 2M installs that work well together, and with the ZHA (3radios). Function and presentation wise, it's swings and roundabouts for me. I think they could learn from each other and both end up stronger.
On Fri, 8 Dec 2023, 07:29 roastcom, @.***> wrote:
From what I've seen m2q rarely has correct pictures of niche devices.
The ones I have are these: 20231208_160220_cr.jpg (view on web) https://github.com/Koenkk/zigbee2mqtt/assets/130372286/e0e0daa5-e820-4139-b149-4ca7b5d8e717 https://www.aliexpress.com/item/1005005590094557.html
I know you have high hopes for this converter, but the way it works in m2q is the external converter is released first and later it's just committed into the 'master branch'. You can look up the actual code here, it's nearly identical to this converter (as it should be) @.*** https://github.com/Koenkk/zigbee-herdsman-converters/commit/54ffe76c8e6ad6d22c402d16b525cd4d273d3c0d
I am surprised though that you say the device works well in ZHA (perhaps you have a different make?). From what I've surmised it's really the device that seems to be the issue - not the drivers. I've abandoned ZHA early on back when it was noticeably lagging in device support (and because it also seemed much easier for me to make a custom converted in z2m by myself), but maybe I should give it another try...
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1846614250, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCQJFNWNE4HVC5HNRQDYIKXT3AVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBWGYYTIMRVGA . You are receiving this because you commented.Message ID: @.***>
One other thing I noticed - these sensors smash HA database like there's no tomorrow. They make 5 updates per second, I had to completely remove them from the recorder.
I knew it was bad, but I didn't know it was that bad. They are not well designed, or at least the firmware is flaky. I have one per room. So I ended up creating an extra network just for them. So my yellow has one ZHA and now two zigbee2mqtt, rather than one. Luckily it all works like well oiled clockwork.
Your solution sounds much better, but I'm very much still learning, hence my brute force approach 😅
On Mon, 11 Dec 2023, 13:39 roastcom, @.***> wrote:
One other thing I noticed - these sensors smash HA database like there's no tomorrow. They make 5 updates per second, I had to completely remove them from the recorder.
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1849999192, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCWC6LRMLS2AKDVQ3O3YI35GRAVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBZHE4TSMJZGI . You are receiving this because you commented.Message ID: @.***>
I'd love to know how you did that, if you can point me in the correct direction please
On Mon, 11 Dec 2023, 13:39 roastcom, @.***> wrote:
One other thing I noticed - these sensors smash HA database like there's no tomorrow. They make 5 updates per second, I had to completely remove them from the recorder.
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1849999192, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCWC6LRMLS2AKDVQ3O3YI35GRAVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBZHE4TSMJZGI . You are receiving this because you commented.Message ID: @.***>
Pretty simple, this is what I put in the configuration.yaml:
recorder:
auto_purge: true
auto_repack: true
purge_keep_days: 5
exclude:
entity_globs:
- binary_sensor.*presence*
- sensor.sun*
- weather.*
I am learning so much, thank you for your help. I'm really enjoying my move from Samsung to Homeassistant
On Tue, 12 Dec 2023, 13:00 roastcom, @.***> wrote:
Pretty simple, this is what I put in the configuration.yaml:
recorder: auto_purge: true auto_repack: true purge_keep_days: 5 exclude: entity_globs: - binary_sensor.presence - sensor.sun - weather.
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1851900739, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCTB7G56UFI2IEI77K3YJBBNHAVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJRHEYDANZTHE . You are receiving this because you commented.Message ID: @.***>
To capture all entities from those devices you probably would need to extend to
- binary_sensor.*presence*
- sensor.*presence*
- number.*presence*
where presence fits the names of those devices.
PS: I'm pretty new to the whole HA thing myself, not even a year in. Honestly at first it was quite infuriating at times. :)
I really appreciate the help, I read as much as I can. But it's nuggets like yours that push me in the correct direction, preventing me reading the wrong stuff👍
On Fri, 15 Dec 2023, 11:56 roastcom, @.***> wrote:
To capture all entities from those devices you probably would need to extend to
- binary_sensor.*presence* - sensor.*presence* - number.*presence*
where presence fits the names of those devices.
PS: I'm pretty new to the whole HA thing myself, not even a year in. Honestly at first it was quite infuriating at times. :)
— Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/18963#issuecomment-1857683705, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDNGCTKT2BTFBF3AST7BGDYJQUGVAVCNFSM6AAAAAA4VYMN3GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJXGY4DGNZQGU . You are receiving this because you commented.Message ID: @.***>
Hi I wrote a quirk for this device on ZHA (I use both flavours of zigbee on my HA yellow).
@3dbluebot there is an open issue on ZHA for this specific device. Could you paste your custom Quirk there for reference?
I've tried adapting multiple ones without success.
Thanks in advance!
https://www.zigbee2mqtt.io/devices/rtsc11r.html _Minimum range (numeric)
Minimum detection range. Value can be found in the published state on the minimum_range property. It's not possible to read (/get) this value. To write (/set) a value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"minimum_range": NEW_VALUE}. The minimal value is 0 and the maximum value is 1000. The unit of this value is m. Maximum range (numeric)
Maximum detection range. Value can be found in the published state on the maximum_range property. It's not possible to read (/get) this value. To write (/set) a value publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"maximum_range": NEWVALUE}. The minimal value is 50 and the maximum value is 1000. The unit of this value is m.
The unit of this value is m
Should be cm not meter.
Link
https://www.aliexpress.com/item/1005005590094557.html
Database entry
{"id":7,"type":"Router","ieeeAddr":"0xa4c1387b77e1a0c5","nwkAddr":9648,"manufId":4417,"manufName":"_TZE204_mhxn2jso","powerSource":"Mains (single phase)","modelId":"TS0601","epList":[1,242],"endpoints":{"1":{"profId":260,"epId":1,"devId":81,"inClusterList":[4,5,61184,0],"outClusterList":[25,10],"clusters":{"genBasic":{"attributes":{"65503":"�@n,i\u001fAn,i An,i!An,i"An,i3An,i8An,i�@n,i","65506":56,"65508":0,"modelId":"TS0601","manufacturerName":"_TZE204_mhxn2jso","powerSource":1,"zclVersion":3,"appVersion":74,"stackVersion":0,"hwVersion":1,"dateCode":""}}},"binds":[],"configuredReportings":[],"meta":{}},"242":{"profId":41440,"epId":242,"devId":97,"inClusterList":[],"outClusterList":[33],"clusters":{},"binds":[],"configuredReportings":[],"meta":{}}},"appVersion":74,"stackVersion":0,"hwVersion":1,"dateCode":"","zclVersion":3,"interviewCompleted":true,"meta":{},"lastSeen":1692079890196,"defaultSendRequestWhen":"immediate"}
Comments
Here is the dp point information I obtained from the supplier:
DP ID | 标识符 | 数据传输类型 | 数据类型 | 功能点属性 -- | -- | -- | -- | -- 1 | presence_state | 只上报(ro) | enum | 枚举值: none, presence 12 | presence_time | 可下发可上报(rw) | value | 数值范围: 1-3600, 间距: 1, 倍数: 0, 单位: s 19 | dis_current | 只上报(ro) | value | 数值范围: 0-1000, 间距: 1, 倍数: 0, 单位: cm 20 | illuminance_value | 只上报(ro) | value | 数值范围: 0-10000, 间距: 1, 倍数: 0, 单位: lux 101 | sensitivity | 可下发可上报(rw) | value | 数值范围: 0-10, 间距: 1, 倍数: 0, 单位: 102 | presence_delay | 可下发可上报(rw) | value | 数值范围: 5-3600, 间距: 1, 倍数: 0, 单位: s 111 | minimum_range | 可下发可上报(rw) | value | 数值范围: 0-1000, 间距: 50, 倍数: 0, 单位: cm 112 | maximum_range | 可下发可上报(rw) | value | 数值范围: 50-1000, 间距: 50, 倍数: 0, 单位: cmExternal converter
Supported color modes
No response
Color temperature range
No response