Shelly integration: add input state to binary sensors

Feature Requests
1

The current shelly integration is missing the state of the input switch. It would be binary sensor and can be taken directly from the api;

Shelly1/status/:

  "wifi_sta": {
    "connected": true,
    "ssid": "ssid",
    "ip": "192.168.1.xx",
    "rssi": -61
  },
  "cloud": {
    "enabled": false,
    "connected": false
  },
  "mqtt": {
    "connected": true
  },
  "time": "",
  "unixtime": 0,
  "serial": 31,
  "has_update": false,
  "mac": "B4E62D555852",
  "cfg_changed_cnt": 0,
  "actions_stats": {
    "skipped": 0
  },
  "relays": [
    {
      "ison": true,
      "has_timer": false,
      "timer_started": 0,
      "timer_duration": 0,
      "timer_remaining": 0,
      "source": "input"
    }
  ],
  "meters": [
    {
      "power": 0,
      "is_valid": true
    }
  ],
  "inputs": [
    {
      "input": 0,
      "event": "L",
      "event_cnt": 30
    }
  ],
  "ext_sensors": {},
  "ext_temperature": {},
  "ext_humidity": {},
  "update": {
    "status": "unknown",
    "has_update": false,
    "new_version": "",
    "old_version": "20200812-090904/v1.8.0@8acf41b0"
  },
  "ram_total": 51112,
  "ram_free": 39508,
  "fs_size": 233681,
  "fs_free": 150600,
  "uptime": 163443
}

Shelly2.5/status/

{
  "wifi_sta": {
    "connected": true,
    "ssid": "ssid",
    "ip": "192.168.1.xy",
    "rssi": -64
  },
  "cloud": {
    "enabled": false,
    "connected": false
  },
  "mqtt": {
    "connected": true
  },
  "time": "",
  "unixtime": 0,
  "serial": 2764,
  "has_update": false,
  "mac": "B4E62D5A4556",
  "cfg_changed_cnt": 0,
  "actions_stats": {
    "skipped": 0
  },
  "relays": [
    {
      "ison": false,
      "has_timer": false,
      "timer_started": 0,
      "timer_duration": 0,
      "timer_remaining": 0,
      "overpower": false,
      "is_valid": true,
      "source": "http"
    },
    {
      "ison": true,
      "has_timer": false,
      "timer_started": 0,
      "timer_duration": 0,
      "timer_remaining": 0,
      "overpower": false,
      "is_valid": true,
      "source": "input"
    }
  ],
  "meters": [
    {
      "power": 7.33,
      "overpower": 0,
      "is_valid": true,
      "timestamp": 0,
      "counters": [
        0,
        0,
        0
      ],
      "total": 0
    }
  ],
  "inputs": [
    {
      "input": 1,
      "event": "L",
      "event_cnt": 3
    },
    {
      "input": 0,
      "event": "L",
      "event_cnt": 7
    }
  ],
  "update": {
    "status": "unknown",
    "has_update": false,
    "new_version": "",
    "old_version": "20200812-090940/v1.8.0@8acf41b0"
  },
  "ram_total": 50296,
  "ram_free": 37748,
  "fs_size": 233681,
  "fs_free": 150600,
  "voltage": 229.64,
  "uptime": 163508
}

“input”: 0 or 1 gives the state of the input switch.

I don’t understand the structure of the integration part completely, but I think it should be added to: binary_sensor.py

2

I thought ison gives the state of the relay, not the switch

There is currently a lot of stuff missing from the integration, the buttons only report battery level and have no actual use for example

3

Hmm you might me right… Let me investigate.

4

Adding an input sensor is a simple matter, but it will not work properly until aioshelly is not listening for CoAP multicast. That’s why we haven’t added this sensor yet. You have to wait patiently.

ison is a relay status, not switch.

1 Like
5

It’s in the status json as input 0 or 1. Changed the first post.

And the latter I don’t understand, but I already thought there would probably be another reason why it wasn’t implemented. Because it’s such a basic feature in my opinion.

Can you explain a bit more about the CoAP multicast? And why the other sensors will work, but this one won’t?

6

This integration uses CoAP not rest API so your code is invalid.

Integration now polls for Shelly device status every 5 seconds. In the case of input_event (e.g. pressing the wall switch that turns on/off the light), the delay of 5 seconds is a lot. When we have multicast listener, the delay will be in milliseconds, which is imperceptible to the user.

1 Like
7

That explains everything. Thanks. I’ll keep using mqtt for now.

8

not 100% sure, but pyShelly package has CoAP multicast support.
Maybe it can be used instead of aioshelly? Or code from it can be used to add support for multicast?

Not sure what was the decision to build a separate library for shelly (I’m sure there must have been a reason), but support for events would be awesome :+1:

1 Like
9

Work in progress https://github.com/home-assistant-libs/aioshelly/compare/main...chemelli74:chemelli74-owncoap?expand=1

3 Likes
10

As I understand this change to CoAP multicast support means better utilization of the clever Shelly firmware -> making this integration local push than polling -> speeding up refresh rate to unpercievable -> making sense for switches to be exposed to HA properly.

That’s AWESOME if you are on this, guys!
Do you see a roadmap releasing this beauty?

11

PR has been merged https://github.com/home-assistant-libs/aioshelly/pull/33
The new aioshelly will be available to users in HA when… the integration is ready. Please wait patiently.

2 Likes
12

Are you willing to test the new version of the Shelly integration?
The integration is based on the new version of the aioshelly library, which already has its own COAP support and doesn’t use external packages, which should eliminate most communication errors (entity unavailability). The library also supports listening to multicast, but so far it is not implemented in the integration.

Repo: https://github.com/bieniu/ha-shelly-own-coap

The package is prepared as a custom component so the shelly directory should be copied to /config/custom_components and restart HA is needed after that.

Thanks for testing.

13

Will do and report back.

edit: Got an error when adding a shelly and reported a bug.

14

So far so good. Added three shellys (a 1, 2 and 2.5) all items are discovered (except the state of the input, but that was expected). Seems to work like before.

I do have some timouts on two devices. The Shelly 1 is mounted near the router, and the Shelly 2.5 is mounted next to a wifi-AC (cabled).
The 2 is farthest away and doesn’t have a timeout.

15

I posted the diff below on issue #42380 (since rejected, as a feature request that belongs here) that -at least in my setup- makes the 3 inputs on the Shelly i3 work. Hope that’s helpful to some of you here :slight_smile:

Note that as I mentioned there “[n]ote that this does not use the right input name […] As seen from the aioshelly example above, the inputs do have their own description, but I couldn’t find a way to expose these through the abstractions. I’m hoping it may be easier for the author”.

diff --git a/homeassistant/components/shelly/binary_sensor.py b/homeassistant/components/shelly/binary_sensor.py
index 1460c62f15..19e8b085f0 100644
--- a/homeassistant/components/shelly/binary_sensor.py
+++ b/homeassistant/components/shelly/binary_sensor.py
@@ -46,6 +46,13 @@ SENSORS = {
     ("sensor", "vibration"): BlockAttributeDescription(
         name="Vibration", device_class=DEVICE_CLASS_VIBRATION
     ),
+    ("input", "input"): BlockAttributeDescription(
+        name="Input",
+        device_state_attributes=lambda block: {
+            "event": block.inputEvent,
+            "count": block.inputEventCnt,
+        },
+    ),
 }
16

Is there any update about Shelly i3’s? Will this be added after the change to multicast?

17

PR for input events is under development now.

1 Like
18

I tried applying the diff that I pasted above to current master (d7f1deeb00) and seemingly everything works with my i3 - the new get_entity_name() code even names the inputs semi-correctly (“devname channel 1 Input” or “channame Input” – ideally we’d drop the “Input” as superfluous, I guess). I’d send the PR, but since you closed the GitHub last time around, I wanted to double-check here :slight_smile:

19
2 Likes
20

Is this including the CoAP multicast support?