Shelly integrations fail to detect button press

DreadN commented 8 months ago

The problem

I have just moved from Shelly 4 Hass to native shelly integration. I noticed that there are button entities to detect when button is pressed on a shelly device.

Updated:

Did some checks and understood that all shelly 2.5 aren't triggering any shelly click event, and the event.* entities generated by integration aren't changing state.
One shelly1 in "momentary press" is triggering long and short clicks, shelly1v3 is the only gen1 shelly working for me now.
Shelly Dimmer 1 are in "one button mode" but they do not trigger any event.

I have mainly Gen1 devices and here's the manual page that states what is the behavior: https://www.home-assistant.io/integrations/shelly/#event-entities-generation-1

Event entities (generation 1)

If the BUTTON TYPE of the switch connected to the device is set to momentary or detached switch, the integration creates an event entity for this switch. You can use this entity in your automations.

Entities are created since i have "momentary press" buttons:

But the entity button is always in "unknown state" and can't be monitored by automations.

Every shelly is set with COIoT unicast to the home assistant integration, at port 5683.

Any ideas on why is not working?

What version of Home Assistant Core has the issue?

core-2023.12.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Shelly

Link to integration documentation on our website

https://www.home-assistant.io/integrations/shelly/

Diagnostics information

home-assistant_shelly_2024-01-03T16-52-33.194Z.log

Tried manual buttonpress at 17:49:59

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 8 months ago

Hey there @balloob, @bieniu, @thecode, @chemelli74, @bdraco, mind taking a look at this issue as it has been labeled with an integration (shelly) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `shelly` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign shelly` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

shelly documentation shelly source _{^{(message by IssueLinks)}}

thecode commented 8 months ago

I don't see these devices in the log.

Please download the diagnostics from the device card in Home Assistant and attach it in a comment.
Please add the following to configuration.yaml, restart home assistant, push the button few times and attach the log.
```
logger:
default: info
logs:
aioshelly: debug 
homeassistant.components.shelly: debug
```
Note: it is better to drag the log into the comment (which will add it as an attachment) and not copy paste as it is hard to read logs in GitHub.

Thanks

DreadN commented 8 months ago

Thanks for the support.

For 1. Here's the diagnostic of that device (it happens with every Shelly Gen1 I have). Shelly device ID: 98f4abf35416 config_entry-shelly-2752af61d85f400d2196661cf561f82a.json.txt

Rgarding 2. Isn't this the bottom option same of activating debug?

I've enabled Debug on Shelly integration and actioned via buttons the roller shutter, see the logs from 17:49:49 and over form 3rd of Jan 2024. Look for device ID: 98f4abf35416

If it's the same the log are already attached in first post, under "diagnostic information". Otherwise i'll modify config yml and re-attach logs.

thecode commented 8 months ago

For 1. Here's the diagnostic of that devices (it happens with every Shelly Gen1 I have). home-assistant_shelly_2024-01-03T16-52-33.194Z.log

This is debug log, not diagnostics, please download diagnostics from the device card of a specific device that has a problem.

Rgarding 2. Isn't this the bottom option same of activating debug? ![image](https://private-user- If it's the same the log are already attached, otherwise i'll modify config yml and re-attach logs.

You can enable debug from the UI, but please restart HA after so we can also see the init of the device. After restart wait a minute and press the button. Disable the debug and attach the debug log with the events (your current log doesn't contain any events)

Thanks.

DreadN commented 8 months ago

This is debug log, not diagnostics, please download diagnostics from the device card of a specific device that has a problem.

You're right 👍 I've changed it in previous post, bad cut&paste.

Here's another of the same device. config_entry-shelly-2752af61d85f400d2196661cf561f82a.json.txt

You can enable debug from the UI, but please restart HA after so we can also see the init of the device. After restart wait a minute and press the button. Disable the debug and attach the debug log with the events (your current log doesn't contain any events)

Ok.

Enabled Debug log from UI
Restarted HA
Waited for "HA has started" notification at bottom left
Did some "button press" on the shelly 2.5
Stopped debug log

Here's the file. home-assistant_shelly_2024-01-03T21-43-39.336Z.log

Tell me if you need something else.

DreadN commented 8 months ago

From logs:

2024-01-03 22:42:10.830 DEBUG (MainThread) [aioshelly.block_device.coap] Adding device F35416 to CoAP message subscriptions
2024-01-03 22:42:10.831 DEBUG (MainThread) [aioshelly.block_device.coap] Sending request 'cit/s' to device 192.168.1.82
2024-01-03 22:42:10.835 DEBUG (MainThread) [homeassistant.components.shelly] Setting up online block device Tapp Studio

You can cross reference button press in logs here:

DreadN commented 6 months ago

Hi

Any chances that this problem could be solved in one of the next milestones?

Memphiz commented 4 months ago

This seems to be a firmware issue. I captured the traffic with shelly 2.5 firmware 1.14.0

As of CoIoT spec in the sensor data packets there should be a value for the inputEvent and inputEventCnt sensor value with ids announced in /cit/d request.

Wireshark shows that inputEvent is always transferred as "" (empty string) and event count does not increment (stays at zero). This is with shelly configured in roller mode and detached switches. As of docs this should be working but it does not.

The input state is transferred though - but it doesn't detect short button presses very well ( I always need to press the button a bit longer to see those state changes which has very low WAF).

issue-triage-workflows[bot] commented 1 month ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

DreadN commented 1 month ago

Issue is still present in 2024.07.04 Channel button are not reporting any interaction on some old generation shelly like Shelly 2.5 and Shelly Dimmer.

Some automation stopped working.

Entity for buttons are present in home assistant but remain in unknown state forever.

zaphood1967 commented 1 month ago

Shelly Button 1 have become completely unreliable for me. Button-Press events are shown in the Shelly-App, but only frequently and quite seldom in HA nowadays. Usually it detects the presence of a button at home, but that's it essentially. Since the change to Events for the Button, this has been a constant issue for me, that makes the Buttons useless.

DreadN commented 1 month ago

This seems to be a firmware issue. I captured the traffic with shelly 2.5 firmware 1.14.0

As of CoIoT spec in the sensor data packets there should be a value for the inputEvent and inputEventCnt sensor value with ids announced in /cit/d request.

Wireshark shows that inputEvent is always transferred as "" (empty string) and event count does not increment (stays at zero). This is with shelly configured in roller mode and detached switches. As of docs this should be working but it does not.

The input state is transferred though - but it doesn't detect short button presses very well ( I always need to press the button a bit longer to see those state changes which has very low WAF).

I've open a shelly support case, they are asking me some tests.

Did some test this morning and it seems that "input" state do change when pressing button, but even is something is coming from shelly from CoIoT packets on port 5683, while checking with TCPDUMP, "input" isn't a parameter that is coming in.

`/config # more tcpoutput.txt |grep input -a5 Connection: close Content-Type: application/json Access-Control-Allow-Origin: * Content-Length: 1271

    {"wifi_sta":{"connected":true,"ssid":"IoT-Studio","ip":"192.168.1.82","rssi":-64},"cloud":{"enabled":true,"connected":true},"mqtt":{"connected":false},"time":"11:16","unixtime":1723626990,"serial":63,"has_update":true,"mac":"98F4ABF35416","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"rollers":[{"state":"stop","source":"input","power":0.00,"is_valid":true,"safety_switch":false,"overtemperature":false,"stop_reason":"normal","last_direction":"open","current_pos":68,"calibrating":false,"positioning":true}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1723634190,"counters":[0.000, 182.391, 186.708],"total":679},{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1723634190,"counters":[0.000, 0.000, 0.000],"total":543}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"temperature":49.33,"overtemperature":false,"tmp":{"tC":49.33,"tF":120.79, "is_valid":true},"temperature_status":"Normal","update":{"status":"pending","has_update":true,"new_version":"20230913-112234/v1.14.0-gcb84623","old_version":"20231107-163214/v1.14.1-rc1-g0617c15","beta_version":"20231107-163214/v1.14.1-rc1-g0617c15"},"ram_total":50728,"ram_free":37828,"fs_size":233681,"fs_free":145580,"voltage":232.24,"uptime":1840} [|http]
    0x0000:  dca6 3283 4afc 98f4 abf3 5416 0800 4500  ..2.J.....T...E.
    0x0010:  05b2 03d4 4000 8006 6d6b c0a8 0152 c0a8  ....@...mk...R..
    0x0020:  0164 0050 8bfc 0007 3df7 197c 05e1 5018  .d.P....=..|..P.
    0x0030:  0acd c07c 0000 4854 5450 2f31 2e31 2032  ...|..HTTP/1.1.2
    0x0040:  3030 204f 4b0d 0a53 6572 7665 723a 204d  00.OK..Server:.M

-- 0x0370: 616c 6964 223a 7472 7565 2c22 7469 6d65 alid":true,"time 0x0380: 7374 616d 7022 3a31 3732 3336 3334 3139 stamp":172363419 0x0390: 302c 2263 6f75 6e74 6572 7322 3a5b 302e 0,"counters":[0. 0x03a0: 3030 302c 2030 2e30 3030 2c20 302e 3030 000,.0.000,.0.00 0x03b0: 305d 2c22 746f 7461 6c22 3a35 3433 7d5d 0],"total":543}] 0x03c0: 2c22 696e 7075 7473 223a 5b7b 2269 6e70 ,"inputs":[{"inp 0x03d0: 7574 223a 302c 2265 7665 6e74 223a 2222 ut":0,"event":"" 0x03e0: 2c22 6576 656e 745f 636e 7422 3a30 7d2c ,"event_cnt":0}, 0x03f0: 7b22 696e 7075 7422 3a30 2c22 6576 656e {"input":0,"even 0x0400: 7422 3a22 222c 2265 7665 6e74 5f63 6e74 t":"","event_cnt 0x0410: 223a 307d 5d2c 2274 656d 7065 7261 7475 ":0}],"temperatu 0x0420: 7265 223a 3439 2e33 332c 226f 7665 7274 re":49.33,"overt 0x0430: 656d 7065 7261 7475 7265 223a 6661 6c73 emperature":fals 0x0440: 652c 2274 6d70 223a 7b22 7443 223a 3439 e,"tmp":{"tC":49 /config # `

Memphiz commented 1 month ago

Your dump shows exactly what I wrote … “event” is an empty string and “event_cnt” is zero. Shouldn’t that be enough input for the shelly support case?

DreadN commented 1 month ago

Your dump shows exactly what I wrote … “event” is an empty string and “event_cnt” is zero. Shouldn’t that be enough input for the shelly support case?

we will see...

DreadN commented 1 month ago

Seems that shelly support isn't able to respond, because shelly Gen1 are old and probably they will not get a firmware fix.

By the way, the http://shelly_ip/status/ page is tracking the inputs.

Memphiz commented 1 month ago

Companies should just open source their abandoned products so we could fix the bugs out selfs sigh

DreadN commented 1 week ago

Companies should just open source their abandoned products so we could fix the bugs out selfs sigh

There are some different firmwares you can put on a shelly 2.5... But thinking about what you're saying, having an open source firmware that can be fixed with a simple recompile could be an optimal solition.

home-assistant / core