Closed fotis3d closed 2 weeks ago
FYI even the Tuya intergration brings only home arm/away arm/disarm and the status.
There should be a log message in the Home Assistant log when that "unsupported devices to choose from" occurs. Without that, it is difficult to provide support.
Ok sorry here it is.
This error originated from a custom integration.
Logger: custom_components.tuya_local.config_flow Source: custom_components/tuya_local/config_flow.py:485 integration: Tuya Local (documentation, issues) First occurred: October 15, 2024 at 22:22:22 (3 occurrences) Last logged: 07:12:47
Device matches whm04_doorbell with quality of 33%. DPS: {"updated_at": 1729020140.1325095, "1": "disarmed", "2": 0, "3": 30, "4": false, "6": true, "12": false, "13": false, "20": false, "21": false, "28": 0, "101": "normal", "104": "TAMPER"} Device matches whm04_doorbell with quality of 33%. DPS: {"updated_at": 1729020218.1887238, "1": "disarmed", "2": 0, "3": 30, "4": false, "6": true, "12": false, "13": false, "20": false, "21": false, "28": 0, "101": "normal", "104": "TAMPER"} Device matches whm04_doorbell with quality of 33%. DPS: {"updated_at": 1729051964.8444636, "1": "disarmed", "2": 0, "3": 30, "4": false, "6": true, "12": false, "13": false, "20": false, "21": false, "28": 0, "101": "normal", "104": "TAMPER"}
I also own a Tuya PGST 107 wifi alarm which I have never used and had gotten it as a spare thinking it is the same. If this one Digoo gets included I will also try to add the PGST 107 in order to add it also in the list of devices that work. If it will work.
Thanks for your time and support
@make-all Hi. Thanks for your support.
I add it choosing as device the "whm04_doorbell" when the list appears.
I get the below entities but none of them seam to do anything.
I cannot at least see the status (armed/disarmed etc).
Am I doing something wrong ? Should I try other devices instead of "whm04_doorbell" ?
Thanks again :)
There should be a separate config for digoo_hamb_alarm
Yes there is one but how do I make use of that ?
I have not quite understand.
I connect the device and have to choose one of the below right ?
And then some entities are created that basically do not respond to anything.
How do I point the device to the specific config file ?
Thanks again for your effort
What is the log message that is output when you see that list? It will contain the clue as to why the digoo_hamb_alarm is not being detected as compatible at dps level.
When the log message at the top is used, the result is as follows, so something must have changed in the behaviour of the device between then and now. It is not uncommon to require 2 or 3 iterations before a tuya device can be reliably detected.
python util/best_match.py '{"1": "disarmed", "2": 0, "3": 30, "4": false, "6": true, "12": false, "13": false, "20": false, "21": false, "28": 0, "101": "normal", "104": "TAMPER"}'
digoo_hamb_alarm matched 100%
alarm_control_panel:
alarm_state: disarmed
trigger: False
sub_class: None
sub_type: None
sub_admin: None
sub_state: None
number_exit_delay:
value: 0
number_alarm_time:
value: 30
switch_alarm_sound:
switch: False
switch_alarm_light:
switch: True
switch_keytone:
switch: False
light_backlight:
switch: False
switch_alarm_call:
switch: False
phone_number: None
switch_alarm_sms:
switch: False
select_zone_activation:
option: None
zone: None
event_alarm:
event: None
message: None
number_entry_delay:
value: 0
binary_sensor_plug:
sensor: True
binary_sensor_battery:
sensor: False
binary_sensor_tamper:
sensor: True
I get these . At the list I choose the doorbell.
I also have intergrated via Tuya. Could this be a problem ?
No, the problem is that in the original report, the TAMPER alarm was being reported on dp 104, but now it is not reported at all. The original config assumed that the dp would always be reported as either "NORMAL" or "TAMPER" as the dp info said.
Oh ok. Do you need anything from me that might help? Thanks again
I think it is fixed, so it only needs testing. If you can copy the latest digoo_hamb_alarm.yaml file into your local install (replacing the one that is there), then that can be done immediately, but otherwise it can be after the next release.
@make-all You are awesome.
It worked. It gave me 15 entities.
I can not test them all now but everyone I tried worked beautifully. :)
When I get back from work I will do more testing and on the next days I will also try my PGST PG-107 to see if it is the same in order for you to include it also in the devices.
Thank you very much for you precious help :)
@make-all I did some tests and everything seams to work fine.
I miss only the "sos" command but this is no issue at all since I can send that via RF control remote or Sonoff RF bridge.
Now I connected also my spare alarm PG-107 (this could also be under Gautone brand) but it connects with the Gautone PG-103 at the list of devices and thus it gives 10 entities instead of 15 that the Digoo gives and they are almost identical.
Is there a way of connecting it at the same yaml as the Digoo or would you like to open a new request and do the same procedure for DPs etc ?
Thanks
The "sos" command should be mapped to the alarm_control_panel.trigger service. I am not sure what the alarm_control_panel UI is in HA, but you could map this to a button that calls that service.
You should file another request for the other alarm. Or if you are sure it is a clone of this Digoo alarm, post the log message when adding it here.
I forgot to mention one thing to improve. I have changed the below lines at least at my yaml file to be more accurate to the alarm functions.
The alarm bell is basically the arm_beep to the central unit BUT the light controlls the SIREN.
Log message
DPS information
Product ID
a4xyigjpkcmfafvh
Product Name
报警主机PG
Information about how the device functions
Mainly as an alarm has home arm/away arm/disarm/sos.
You can do those funtions with RF remote which is what I am doing with a Sonoff RF Bridge via mqtt.
The most import thing is to get local the status (home/away arm, disarmed).