Shelly binding - support shelly 1 plus

Hi

I have been using successfully openhab with shelly binding controlling shelly 1 , shelly 2.5 and shelly dimmer 2
recently I added additional Shelly 1 plus to my home but the binding fails to detect it.
Is the binding support the new shelly plus products ?

The integration for the Shelly Plus devices is not ready yet.
See the Shelly Binding Thread:

Today I recognized that openhab3 not yet supports Shelly 1 plus. Is there a way to use at least the switching with a existing config?
Thanks
Michael

Unfortunately not through openHAB, until such time @markus7017 can revise the binding to work with Shelly’s updated API. I have one switch installed and am just connecting to it directly via my web browser.

The Plus switches look nice and I’m interested in seeing some of the Pro devices once they’re released. But Markus is doing that work on his personal time, so we must be patient!

I did some investatigations and I am now able to switch with mqtt.

I used

mosquitto_pub -h millipede -t shellyplus1-441793944cbc/rpc -m '{"id":0, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":true}}'

for on and

mosquitto_pub -h millipede -t shellyplus1-441793944cbc/rpc -m '{"id":0, "src":"user_1", "method":"Switch.Set", "params":{"id":0,"on":false}}'

for off.

I also added a state topic

shellyplus1-441793944cbc/status/switch:0 {"id":0, "source":"MQTT", "output":true, "timer_started_at":1640964511.39, "timer_duration":3600.00,"temperature":{"tC":60.0, "tF":140.0}}

for on and

shellyplus1-441793944cbc/status/switch:0 {"id":0, "source":"MQTT", "output":false,"temperature":{"tC":60.5, "tF":140.9}}

for off

For some reason the jsonpath convert does not work
The log shows

21-12-31 17:06:06.871 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '{"id":0, "source":"WS_in", "output":true, "timer_started_at":1640966767.65, "timer_duration":3600.00,"temperature":{"tC":59.6, "tF":139.3}}' not supported by type 'OnOffValue': No enum constant org.openhab.core.library.types.OnOffType.{"id":0, "source":"WS_in", "output":true, "timer_started_at":1640966767.65, "timer_duration":3600.00,"temperature":{"tC":59.6, "tF":139.3}}

I am not a json expert so maybe somebody can provide some help?

Thanks
Michael

Hi,

I have a shelly plus 1PM working in Openhab through MQTT. I configured only switch and current power functionality.
This is my thing config:

UID: mqtt:topic:533dd02985:shellyplus1pm-441793952cc4
label: Heizung Bad
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:533dd02985
location: Bad
channels:
  - id: Switch
    channelTypeUID: mqtt:switch
    label: Bad Heizung Ein/Aus
    description: ""
    configuration:
      commandTopic: shellies/shellyplus1pm-441793952cc4/rpc
      formatBeforePublish: '{"src":"chan_1","method":"Switch.Set", "params":{"id":0,"on":%s}}'
      stateTopic: shellies/shellyplus1pm-441793952cc4/chan_1/rpc
      transformationPattern: JSONPATH:$.params.switch:0.output
      off: "false"
      on: "true"
  - id: badHeizungSwitch_power
    channelTypeUID: mqtt:number
    label: Watt
    description: ""
    configuration:
      stateTopic: shellies/shellyplus1pm-441793952cc4/events/rpc
      transformationPattern: JSONPATH:$.params.switch:0.apower

And this is the MQTT config on the shelly itself:

I hope this helps someone, until the shelly binding is adapted…

best regards
-xs

EDITED 19.01 due to better understanding of return payloads

Getting into the entire home automation as of recently, and faced the same obstacle of binding and connecting with a Shelly Plus 1. The posts by @Michael_Andres and @xsived didn’t work entirely, but they were valuable breadcrumps, so I figured I would contribute for everyone else who comes across this thread trying to deal with the Shelly Plus 1 and its API. (I kind of get why it’s shaped as it is, but What The Hell Documentation…)


Enviroment

  • Shelly Plus 1, Firmware 0.9.2
  • Raspberry Pi 4
  • openHAB 3.2 on openhabian
    • MQTT Binding 3.2.0
    • Mosquitto MQTT Broker, version 2.0.11, via the openhabian configuration tool

Shelly Configuruation

  • Connection Type was MQTT
  • Device name was as generated, so shellyplus1-<alphanumerics> though one should be able to change this without much issue… just didn’t want to touch this after everything else worked fine.
  • RPC status notifications over MQTT was enabled
  • Generic status update over MQTT was disabled
  • broker and IP was set as normal
  • as were the credentials

Channel Configuration

This channel configuration can be done with either code or over the UI with advanced settings shown.

State Topic was <shelly-name>/events/rpc. On this topic the Shelly publishes JSON files whenever events happen to it, such as that the connected switch is operated manually.

CommandTopic was <shelly-name>/rpc.

QoS was set to “Exactly once”.

Retained was on.

IsCommand was Off.

Custom On/Open Value was true. Custom Off/Closed Value was false.

Incoming Value Transformation should be set to JSONPATH:$params.switch:0.output to get the status of the relay. ( JSONPATH:$params.input:0.state gets you the event properties of the switch input to the Shelly)

Outgoing Value Transformation was empty.

Outgoing Value Format was {"id":123,"src":"light","method":"Switch.Set", "params":{"id":0,"on":%s}}

To explain this format a bit. One must provide an ID and source statement. The ID statement is basically arbitrary but is supposed to let different command entities be differentiated. The src statement will be used for publishing a return message on the MQTT topic <shelly-name>/<src-argument>/rpc sent by the Shelly on reception of one’s command message. This will be a message about the previous state of the switch if successfull, and an error message if the JSON is invalid. One must provide a method argument, and then a params JSON object. This object contains the ID of the switch (in the case of the Shelly Plus 1, this is just “0”) and a boolean statement about whether the switch being on is true, or false.


If this fails to work, chances are

  • one isn’t publishing messages to the right topic where the Shelly is actually listening. In this case it can help to have the MQTT broker log all subscription and messaging activities, which will include subscription messages from the Shelly, or have a Broker that can provide this information to you over some UI.
  • one is subscribed to the wrong topic for getting the event messages the Shelly posts when it is controlled through a hardwired (light) switch, or reading the JSON incorrectly. In this case, use console utilities like mosquitto_sub subscribe to the topic where the Shelly is posting events and read out the JSON for yourself, or again, use other MQTT tools to get a handle on the traffic that’s happening.

Doing those two things is what ultimately solved it for me.

In the case of this set-up, when the manual light switch was used, the Shelly posted two updates over the topic <shelly-name>/events/rpc. One was this:

{
	"src": "shellyplus1-<name>",
	"dst": "shellyplus1-<name>/events",
	"method": "NotifyStatus",
	"params": {
		 "ts": <number>,
		 "input:0": {
			 "id": 0,
			 "state": <boolean>
		 }
	}
}

this informs you about the state of the input:0 switch input to the Shelly, you might have wired a light switch to that one.

Another one has a format like this:

{
	"src": "shellyplus1-<name>",
	"dst": "shellyplus1-<name>/events",
	"method": "NotifyStatus",
	"params": {
		"ts": <number>,
		"switch:0": {
			"id": 0,
			"output": <boolean>,
			"source": "switch"
		}
	}
}

this is the interesting one if you want the current output status, be it due to your own commands or because the lightswitch was used to toggle the Shelly via hardware. Hence JSONPATH:$params.switch:0.output is the correct incoming value transform.

this is all of as 0.9.2, and Shelly seems to be pushing out new versions all the time, so this may stop working at some point.

I hope this helps some people.

4 Likes

Hi!
Maby this helps:

Great summary @FjerHAB without diminishing the initial work done by @Michael_Andres and @xsived - Thx to you all.
I added one improvement to the Incoming Value Transformation.
Just as @FjerHAB mentions, the Shelly posts two updates when the switch on de Shelly is triggered.
The JSONPATH Transform picks up one of them accurately but the other update does not match the transform and instead creates an warning message in the log such as the below example.

2022-03-12 10:04:08.975 [WARN ] [t.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path ‘$.params.switch:0.output’ in ‘{“src”:“shellyplus1-7c87ce5633f8”,“dst”:“shellies/shellyplus1-7C87CE5633F8/events”,“method”:“NotifyStatus”,“params”:{“ts”:1647075849.93,“input:0”:{“id”:0,“state”:true}}}’

I stole the very easy cleanup from @denominator post on the same topic, and just added a REGEX before the JSONPATH Transform to filter out the non-wanted posting.

Incoming Value Transformation now looks like this:

REGEX:(.switch:0.)∩JSONPATH:$.params.switch:0.output

3 Likes

jfyi: I‘m just completing the integration into the regular binding, today I‘ll post another build; follow us here:

1 Like

A first build is available, see Shelly Binding - #2464 by markus7017. Please continue discussion within the main thread and close this one.