Edge Shelly drivers for Gen1 and Gen2 Devices

Interesting! Sorry for missing crucial details. I also could not find password settings in Shelly apps. I have a pair of Shelly PlugS-es, and I used the plugs’ own web interface to configure them. It’s a single password field, same password for websocket and HTTP.
For Gen2 devices, they use standard HTTP Digest auth with SHA-256. Username is always “admin”, no way to change it. I was able to control the password-protected device from a NodeJS script, but I have no clue about Lua. Chrome’s built-in HTTP auth integration also seems to work fine, confirming it is some kind of standard.


1 Like

That’s very helpful, thanks. I wondered if perhaps it was only available through the web interface!

So your immediate desire is to have authentication for Gen1 devices as opposed to Gen2? I found the documentation regarding Gen2, but haven’t come across it yet for Gen1. If you know where it is, let me know.

1 Like

I found something on Gen1:

All resources except for /shelly will require Basic HTTP authentication when it is enabled via /settings/login

So it uses Basic, which I needed to know. The next thing I’d want to confirm is if the login settings are set when you do the setup through the device web page. Can you please check this by putting this in a browser address bar?:

http://<device IP>/settings/login

It should return something like this:

{
"enabled": true,
"unprotected": false,
"username": "admin"
}

I’m looking to confirm that it shows enabled is true if you’ve gone ahead and defined a password for the device through the web page.

I think it is a Gen 2 device. I dug up the box it came in, it says “Shelly Plus Plug S”. I have a local DNS entry for the plug that’s why there is no IP in the URL.

I did not find a username in any of the responses, I think it is just hardcoded to "admin".

The auth method is HTTP Digest Auth. Unfortunately, it is a tad bit complicated. It works by invoking an arbitrary protected endpoint first, which gives us an auth challenge in the www-authenticate header, and then we need to calculate a new digest for every subsequent request. Quite clever actually.

$ curl -s 'http://shellyplug1.sanctuary.home/rpc/Shelly.GetDeviceInfo' | jq
{
  "name": "Iron Socket",
  "id": "shellyplusplugs-xxxxxxxxxxxx",
  "mac": "xxxxxxxxxxxx",
  "model": "SNPL-00112EU",
  "gen": 2,
  "fw_id": "20230510-081027/0.14.4-g4da93ee",
  "ver": "0.14.4",
  "app": "PlusPlugS",
  "auth_en": true,
  "auth_domain": "shellyplusplugs-xxxxxxxxxxxx"
}


$ curl -s 'http://shellyplug1.sanctuary.home/shelly' | jq
{
  "name": "Iron Socket",
  "id": "shellyplusplugs-xxxxxxxxxxxx",
  "mac": "xxxxxxxxxxxx",
  "model": "SNPL-00112EU",
  "gen": 2,
  "fw_id": "20230510-081027/0.14.4-g4da93ee",
  "ver": "0.14.4",
  "app": "PlusPlugS",
  "auth_en": true,
  "auth_domain": "shellyplusplugs-xxxxxxxxxxxx"
}


$ curl -s 'http://shellyplug1.sanctuary.home/settings/login'
Not Found


$ curl -s -i 'http://shellyplug1.sanctuary.home/rpc/Shelly.GetConfig'
HTTP/1.1 401 Unauthorized
Server: Mongoose/6.18
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: *
Content-Length: 0
Connection: close
WWW-Authenticate: Digest qop="auth", realm="shellyplusplugs-xxxxxxxxxxxx", nonce="650f39bc", algorithm=SHA-256


$ curl --digest -u admin:xxxxxxxxxxxxxxxxxx -s 'http://shellyplug1.sanctuary.home/rpc/Shelly.GetConfig' -v
*   Trying 192.168.191.32:80...
* Connected to shellyplug1.sanctuary.home (192.168.191.32) port 80 (#0)
* Server auth using Digest with user 'admin'
> GET /rpc/Shelly.GetConfig HTTP/1.1
> Host: shellyplug1.sanctuary.home
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Server: Mongoose/6.18
< Content-Type: application/json
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: *
< Content-Length: 0
< Connection: close
< WWW-Authenticate: Digest qop="auth", realm="shellyplusplugs-xxxxxxxxxxxx", nonce="650f3d5c", algorithm=SHA-256
<
* Closing connection 0
* Issue another request to this URL: 'http://shellyplug1.sanctuary.home/rpc/Shelly.GetConfig'
* Hostname shellyplug1.sanctuary.home was found in DNS cache
*   Trying 192.168.191.32:80...
* Connected to shellyplug1.sanctuary.home (192.168.191.32) port 80 (#1)
* Server auth using Digest with user 'admin'
> GET /rpc/Shelly.GetConfig HTTP/1.1
> Host: shellyplug1.sanctuary.home
> Authorization: Digest username="admin", realm="shellyplusplugs-xxxxxxxxxxxx", nonce="650f3d5c", uri="/rpc/Shelly.GetConfig", cnonce="ZTVhOTViZTc0MzAwMmU0YzBiNjk2ODQzMTcyNTc1Yjg=", nc=00000001, qop=auth, response="3c6d552fbdaff328cb013a9f209f445e0e0bed4ab3c07c2ab1d24533dc246efd", algorithm=SHA-256
> User-Agent: curl/7.81.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: Mongoose/6.18
< Content-Type: application/json
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Headers: *
< Content-Length: 1783
< Connection: close
<
...

Ok thanks for clarifying it is Gen2. I have implemented digest authentication for other drivers, so am familiar with it.

I was going to say that for Gen1, I’m not sure why anyone would bother with using authentication since it just uses Basic, which is quite easily defeated.

Shelly Gen2 Driver Update Notice

Name: Shelly Gen2 Device Driver V1.5
Driver ID: f3258c1d-b6e9-424d-8b3f-b1e8fe51c4ca
Version: 2023-09-25T18:57:32.621319938


In this update I have improved detection of when the Shelly device has gone offline due to something like a sudden power loss or being intentionally disconnected.

Previously, the driver may not be aware the device is no longer connected, and may not re-connect with the device when it was back online. The symptoms you may have experienced in this case are that updates were no longer being reflected in the SmartThings device, or attempting to control the device from SmartThings was no longer working.

This driver update implements a periodic monitor to check that the device is still connected, and if not, it will be shown as offline in the Smartthings app and reconnection attempts will be started and run every 15 seconds. The monitor checks status every 2 minutes, so any device that has been disconnected should be detected within 2 minutes.

I want to thank @BobR for highlighting this issue and helping me test the fix.


This update also includes code to support password authentication, however it is currently implemented only for plug-type devices, pending further testing. If anyone wants to try this out, you will have to use the web page interface to the Shelly plug device in order to enable authentication and set a password. That password then needs to be configured in the SmartThings Shelly plug device Settings screen. Once this new feature has been further tested I will expand it to all device types.


Still reading this? Here is extra credit work:

Run logs for the Gen2 driver and report back to me the frequency your device is sending these ‘ping’ notices:

2023-09-26T16:48:06.229401372+00:00 DEBUG Shelly Gen2 Device Driver V1.5  Plus PlugUS 1 received opcode=9.0, c=nil, d=nil, err=nil
2023-09-26T16:48:12.324596208+00:00 DEBUG Shelly Gen2 Device Driver V1.5  Plus PlugUS 1 received opcode=9.0, c=nil, d=nil, err=nil

I’d like to collect more data on what frequency each device type is using because I’ve found that it varies by device type. For example, in the above example, the US Plug device sends them every 6 seconds. This data will help me ensure optimal online monitoring frequency that works well for all devices.

1 Like

Thank you very much! That fixes the problem with my Shelly add-on not reporting temperature after the loss of internet connection.

TAustin via SmartThings Community <notifications@smartthings.discoursemail.com> escreveu no dia terça, 26/09/2023 à(s) 18:04:

3 Likes

Hi @TAustin. Finally think I’m getting the hang of your great drivers. A question for you (which I can see sort of addressed above but I’m still not clear). I’ve a Shelly 2 Dimmer module. I’d like to trigger actions on short / long press.

I can see the input state for the switch, but as you’ve flagged above, I only see “on” or “off” rather than whether the status is “long” or "short.

I noticed on the following at this url:

shellies/shellydimmer-<deviceid>/longpush/<i> for each SW input <i>; reports a value indicating longpush state as 0 (shortpush) or 1 (longpush)

Can this information be captured via your driver or is there an alternate way to capture a long/short press? I’ve got the button set to “detatched”.

I’ll have to add inputs fields to that device. I can implement them as buttons so that you could trigger off of the short vs. long push. So yes, it can be done, give me a week or so and I’ll try to have it ready for you to test out.

1 Like

Fantastic. I look forward to it. It should make single switch setups much more powerful.

Hello @TAustin. Great job you are doing here. The drivers are AMAZING :blush:. Any plans for Shelly Mini drivers?

The API docs show these as basically equivalent of the Shelly Plus 1 and 1PM products. They have a unique device identifier, which I will have to add so the driver would recognize them. So it shouldn’t be a problem. Do you have these products we could test?

Hi @TAustin. Yes I have all 3 of them. Would be more than happy to test them. The Plus 1PM Mini, the Plus 1 Mini and the Plus PM Mini.

Great - could you please do the following for each of those 3 device types: Find out the IP address for each device, and in a browser address bar, enter:

<ip address>/shelly

So for example

192.168.1.120/shelly

You’ll get back some JSON and I’m looking for the ‘id’ fields to confirm the device type ids being used.

You can DM me the results.

Shelly GEN1 Driver Update Notice

Channel: My Test Driver Link
Name: Shelly Device Driver V1.8c
Version: 2023-09-29T17:12:24.050775954

Updates:

  • Devices will now show offline if they are not responding to periodic check. This periodic check happens every 30 minutes, so it could take up to 30 minutes for a device to be determined offline. This check is much less frequent than the GEN2 driver due to known issues with the GEN1 device firmware. I’ll continue to look at other alternatives to improve this.
  • Dimmer device: @chips Added button fields to the input components to enable triggering off of short vs long button presses on the device. Short == ‘pushed’, Long == ‘held’
1 Like

Follow up to my previous post. I’m pushing out another update to the GEN1 driver that further improves device offline indications for those with auto-refresh enabled. Offline devices will be shown as such within about 15 seconds of the last refresh if the device is unreachable.

Additionally, the periodic device connection check frequency has also been increased to be every 5 minutes.

Version: 2023-10-03T00:15:30.159940943

1 Like

Does the shelly motion shows the temperature in the Smartthings app?
@dcnilas11

Hi,

I just have the Shelly Motion with the official integration, and no, don’t show the temperature.

1 Like

In case you would be interested, I plan on adding the Gen1 motion devices to my Shelly MQTT driver for battery-powered devices. I used to be able to support the motion 1 device with my standard Gen1 driver, because it would stay awake on the network, but that seems to no longer be the case. When I implement that I’ll be including the temperature values from the Motion 2 devices.

2 Likes

thanks…I will buy the Motion 2 devices because it has temperature capability

1 Like