-
Notifications
You must be signed in to change notification settings - Fork 489
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tuya Photoelectric Smoke Detector _TZE200_m9skfctm #6734
Comments
Testing following DDF
|
Create DDF for Tuya Photoelectric Smoke Detector _TZE200_m9skfctm Description is in dresden-elektronik#6734
Will be able to add another attribute regarding smoke ppm when PR #6673 will be merged
|
I am new to this, I dont know if I can add a comment to closed issues. But anyway I try: Behavior is not as expected: I tried 2 identical sensors, same bevior Here is some more Info, I hope that helps: `Homebridge warning at restart: [14.2.2023, 11:00:00] [Hue] Phoscon-GW: /sensors/20: warning: unknown ZHAFire sensor {"config":{"battery":100,"on":true,"pending":[],"reachable":true},"etag":"4e906bbc13b13bd9446cadbc266ebe31","lastannounced":null,"lastseen":"2023-02-14T09:59Z","manufacturername":"_TZE200_m9skfctm","modelid":"TS0601","name":"Fire 20","state":{"errorcode":"false","fire":true,"lastupdated":"2023-02-14T09:52:51.464","test":false},"type":"ZHAFire","uniqueid":"a4:c1:38:3f:87:e4:8b:ae-01-ef00"}`
|
Hi. A bit weird because mine is fully functional with that DDF and a test returns an event with test:true. Do you mean that you have a fire alarm but the device does not make a at noise ? I don’t see any version information in your request. Then I suppose that you don’t have the tuya_version.js under your local directory. Can you make a screenshot from DeConz GUI basic cluster to show the version please (may be a new firmware ?) |
When I press the butten the device make the beep beep beep... until I press again. Looks normal. |
My configuration: |
Yes that's the test button. Then you should have an event in Phoscon with
Where is it still present ? In Deconz, Phoscon, Homebridge ? Everywhere ? How did you delete it ? |
still the same, when I hit the test button, "test": true. Regarding "removal" and start all over: This is how I did it: BTW: The device has never been visible in Phoscon but I learned that that is normal for temporary DDFs. What would be the correct way/sequence of actions to remove the 2 smoke devices currently paired and start all over ? Any ideas about the warning message in homebridge? "phoscon-GW: /sensors/19: warning: unknown ZHAFire sensor etc..." ? |
Got exactly the same ... I don't really care about Phoscon for this device... I sometimes used it just to have a friendly gui to access some information like json ;-) It's weird that your device present To delete a device, it's seems you did it like it could be done. Perhaps you could try to delete the device before remove battery and restart deconz bfore putting the battery back and repairing the device. It's strange that the device stay after delete. You say that you have two of them, is it the previous "deleted" one and the second the device after rejoining ? Do they have different sensor id ? And how could Deconz handle the same Could you provide for both what you called API-Info previously ? |
The 2 devices are different, got different Mac/NWK, there is no mix, deconz and all other components process that correctly. I paired fire-20 this morning for the first time just to see if it behaves the same as fire-19. |
Ok I understand. And you’re right, chances to get two faulty devices at the same time … hmmm 🤔 |
I could not reproduce that the device is still visible somewhere after removal in deconz. Maybe I fell into a trap with data from cache. I played around a bit in the DDF setting the default to different values like "0" and "false" or empty etc - no change. |
Yes, it is !
Not he idea of the century for sure : did you try to click in basic cluster on exec button to reset to factory default ? In the mean time could you get some log with just INFO and DDF checked ? it's sufficient to get DDF evals and Tuya request/response ? |
I hit the exec button. But nothing really happened. I would expect that the device would require repairing after factory reset but it just continued working and spreading "fire: true". BTW: swversion is null or that line is missing in event records.
In the DDF it shows:
I don´t see a script file "tuya_swversion.js" in my Home dir. Could that be a problem? |
It shouldn't. You can make a copy of
In fact you already gave it previously here. Can you propuce it again with just INFO and DDF checked ? |
To be very honest, I based my DDF on other plateform information (ie : Koenkk/zigbee-herdsman-converters@1ca479c) but I have some doubt about what In that case the eval part of the DDF should be : "eval": "Item.val = (Attr.val == 0);" |
Thanks a lot for your great support and fast replies - and the patience with me... Step by step - I hope I am not presenting this in a too confusing way. My simple observation:
|
I did the above without pairing again - just restarted deconz and inserted the battery into the device. Is that sufficient? |
I think I got the solution, in addition to setting value you need to change default to 1 - then it works.
|
That's clearly what we were waiting for these two attributes ! ;-)
From my experience a hot reload only works after modified the DDF using DDF editor and saved the file. And sometimes you loose the swversion definition doing that way. Then modifying DDF using text editor and restarting DeCONZ is the best way at this time to be sure that the DDF is used at startup. No need to repair if you don't change subdevice or endpoints inside the DDF.
Are you sure ? Doing that means that if value couldn't be parsed then Could you try this other formula and keep |
I think we entered our comments at the same time. Strange, normal people would think 1 if fire - but in fact for tuya 0 seems to be fie alarm. Thanks a lot for your great support. Greetings from the Lake of Constance |
Yes for this kind of device it seems to be that way internaly, but for HA systems, fire race is when fire attribute is true. That's why we have to invert he logic and made the attribute fire to be true when tuya send 0, and false otherwise. That's why I think that default to true seems very weird. |
I will try your settings tomorrow and get back to you.
|
works. No problems found. Tested essential funktions (idle, alarm, battery change), everything fine. Looks probably better than default =true |
Many thx 🙏 |
* Add DDF for Tuya Photoelectric Smoke Detector _TZE200_m9skfctm Create DDF for Tuya Photoelectric Smoke Detector _TZE200_m9skfctm Description is in #6734 * Invert the fire logic For this tuya device 0 means fire
Device
Screenshots
Basic
Groups
Scenes
Information found here and here
The text was updated successfully, but these errors were encountered: