This is a lollow up of the " Shelly Plus 2PM (Gen2) REST command error · Issue #125156 · home-assistant/core (github.com)" on 03/09/24. Please have a look to it, I explain in detail the problem with the Shelly Gen2 REST command. It was closed by @thecode, but the problem seems to be due by some differencies between the Gen1 API and the Gen2 not addressed by HASS developpers? The HTTP endpoint command is supposed to be compatible between Gen1 and Gen2, as stated by the instructions: Cover | Shelly Technical Documentation. @thecode says that the problem must be addressed by Shelly, but Shelly support says that it must be addressed by HASS developers. The following is their email answer:
The issue with the “current_pos” and “last_direction” attributes not being available in the Shelly integration for Home Assistant is known. Your workaround with the REST sensor is a good approach. The error you’re encountering with the HTTP endpoint might be due to differences in the API between the 2.5PM and Plus 2PM.
The Home Assistant integration for Shelly devices is developed by the Home Assistant community, and while we provide support, we do not directly develop the integration.
You can report this issue on the Home Assistant GitHub page or their community forums to get more visibility and possibly a quicker resolution.
I’m not sure wether this is the right place to report this problem, but indeed needs to be solved.
Thank you very much
You are sending REST commands to the device, so you are doing something that has nothing to do with Shelly integration in HA. For this reason, your issue has been closed.
I recommend to use Cover.Close, Cover.Open and Cover.GoToPosition services:
@Bieniu I’m using REST because I need to use time (duration) and not position, because moving 1% (minimum movement) up or down, once you get the desired position, is too much to tilt the blades.
@Bieniu Exactly, this is why I opened a feature request to be able to use time with duration and last_direction to adjust the blades. Position only allows 1% minimum change and it is too much to tilt the blades.
As a workaround, I’m trying to use HTTP endpoint with a REST sensor and command, mentioned above, and gives an error with Gen2 devices.
The device does not offer such possibility via RPC, so how would such functionality be implemented (ignoring the fact that this would require a change to the entire cover platform)?
@Bieniu The device indeed offers the possibility to use duration and last_direction!! I’m not sure I understand your question? In fact, to be able to have this functionality, my workaround is to create a REST sensor, as extended of the cover, to get the parameters from the Shelly cover (jointly with the device IP address), and then, create a REST Command to be able to call it from a button or automation, to tilt the blades after any movement. The command tilts the blades up or down in function of the last_direction, and uses duration because it’s more accurate than using position, which moves the blades too much, since it uses a minimum of 1%.
The following is the yaml code I use, so as you can understnad better my proposal:
### rest_commands.yaml ###
persiana_tilt_open_close:
url: "http://{{ ip_address }}/roller/0?go={{ tilt_open_close }}&duration={{ duration }}"
method: PUT
### sensors.yaml
# Shelly last_direction Persianes
- platform: rest
name: "Persiana 1 Carrer extended"
#resource: http://192.168.131.180/status ##Gen1 devices
resource: http://192.168.131.180/rpc/Shelly.GetStatus
method: GET
scan_interval: 2
#json_attributes_path: "$.rollers[0]" ##Gen1 devices
json_attributes_path: "$.cover:0"
#value_template: "{{ value_json.wifi_sta.ip }}" ##Gen1 devices
value_template: "{{ value_json.wifi.sta_ip }}"
json_attributes:
- "state"
- "current_pos"
- "last_direction"
unique_id: "sensorPersiana1CarrerExtended"
### tap_action of the button in custom button card ###
tap_action:
action: "call-service"
haptic: "medium"
service: "rest_command.persiana_tilt_open_close"
service_data: |
[[[
//cover rest sensor_extended defined in sensors.yaml//
var sname = "sensor." + variables.var_basename + "_extended";
var ip = null;
var ld = null;
var dur = null;
var til = null;
ip = states[sname].state;
ld = states[sname].attributes.last_direction;
if (ld == 'open') {
dur = variables.var_orient_close;
til = 'close';
} else {
dur = variables.var_orient_open;
til = 'open';
};
return {"entity_id": "entity", "ip_address": ip, "tilt_open_close": til, "duration": dur};
]]]
Shelly integration and aioshelly package uses RPC protocol to communicate with Gen2/3 Shelly devices. GotToPosition service for Cover component for RPC protocol does not support duration.
At least, providing the duration and last_direction in the cover entities (maybe also the IP) will make easier to use them through a REST Command avoiding to also create a REST sensor, to be able to tilt the blades of the cover…
@Bieniu Interestingly, I created a REST Command with the Cover.Open and Close and it works! You need to use GET instead of PUT. so definitely providing the duration, last_direction and IP in the cover entities will be extremely useful to tilt covers! The following is the REST Command:
cover_tilt_open_close:
#tilt_open_close=<open_or_close>&duration=<duration>
#url: "http://{{ ip_address }}/roller/0?go={{ tilt_open_close }}&duration={{ duration }}" ##Gen1 devices and works with Gen2 as stated in documentation but gives an error in HASS
url: "http://{{ ip_address }}/rpc/Cover.{{ tilt_open_close }}?id=0&duration={{ duration }}" ##Gen2 devices
method: GET
The main problem is that the cover platform does not support the duration of the movement, only the position. I don’t think it’s a good idea to change the whole platform to achieve tilt. Tilt must be implemented in the device’s firmware and then the integration will support this feature.
The new version of the device (Shelly 2PM Gen3) supports tilt and it will be supported by the integration.
From what I know, Shelly Pro 2PM and Shelly Pro Dual Cover PM will also get this feature with the new firmware. Plus 2PM probably won’t get tilt due to hardware limitations.
If duration is not provided, Cover will fully open, unless it times out because of maxtime_open first. If duration (seconds) is provided, Cover will move in the open direction for the specified time. duration must be in the range [0.1…maxtime_open ]Optional
In case, providing at least “last_direction” (and if possible IP address) in the cover entities will avoid having to create a REST sensor, if you want to tilt the blades by using a REST Command…
