Shelly Wall Display

🛎️ Get Help Devices
1

Anyone got their grubby paws on a Shelly Wall Display yet and got it hooked up to HE in any way?

I just got one and so far all I've tried to do is see if the "Shelly Plus" and "Shelly Wall Switch" drivers could even see it on the network.

The "Shelly Plus" driver at least sees it, does not control the relay. Tells me that firmware is available, etc....

Simon

2

It seem to be not yet documented <Welcome! | Shelly Technical Documentation>

Can you post what components it has? Knowing components list it is possible to try to add support without device at hand.

This driver has autodetection capabilities. It should report all components and spawn compatible child devices. Atm it supports: cover, cloud, em, emdata, eth, humidity, input, script, switch, temperature and wifi components
Shelly Device Handlers for Hubitat - :gear: Custom Apps and Drivers / Custom Drivers - Hubitat

image
image797×680 46.2 KB

3

Humidity is the only thing coming through..... Temperature and Watts (presumably the power being used on the output, if I can something connected).

image
image1351×522 43.1 KB

image
image1042×435 15.1 KB

4

Try to press "configure" and refresh page afterwards. Data section needs browser to refresh the page

5

The logs show this............

image
image933×197 45.1 KB

6

This looks like http error. Need to think a bit about it... Figure out if this is the driver issue or HE API..
I mean a reaction to explicit character set in the device reply..

7

image
image1581×739 149 KB

image
image1130×773 143 KB

8

image
image1602×617 25.2 KB

9

After I turned on the output relay and then turned it off again....

image
image941×338 65.3 KB

10

According to logs it faces an error while trying to get component list. Without component list it can't spawn child devices. (null) means it got event/notification but has no child device to forward to.

A warning shows new component type drivers does not knows yet how to handle. Illuminance sensor related component. This one I will add after fixing the main problem.

It definitely has switch component. So your built-in relay should be controllable in the end. The support for it is already in.

P.S.: Ok! I see the problem. Response error check is too strict. It is on the driver side. Will fix this and update the driver tomorrow)

11

I updated the driver (itself and some child device drivers):

  • HTTP validation is relaxed (ignores charset and other attributes that might also come in)
  • Added illuminance sensor child device. I cannot test this one. It is not documented. So more like a guess. Notification should work correctly (if to rely on your logs). 'Refresh' call needs testing. I assumethere is a related GetState command. But.. Well.. Documentation has no mentions about it. Pure guess.
  • Fixed humidity sensor component device name. A typo were potentially blocking proper instance creation.

A full component list might help to add support for other functionality. Warnings in log will show what handlers are still missing (even if not documented)

P.S.: I suspect there might be one more bug in the error logging routine. This one might be related to authentification fail report. I'm going to try to simulate it locally using what I have.

P.P.S: Code seem to be correct if to believe to documentation. I added additional log entry before error itself to see what comes in (when logs enabled)

1 Like
12

image
image1353×888 169 KB

1 Like
13

image
image1329×530 42 KB

image
image1260×742 24.9 KB

14

Illuminance and Humidity appear and disappear under "Current States" - I believe this is because they need to be defined as Attributes in the driver for them to remain visible. Temperature never appears.

image
image1384×319 33.5 KB

15

I added more logging to HTTP requests to see what JSON content comes in.

Illuminance and Humidity appear and disappear under "Current States" - I believe this is because they need to be defined as Attributes in the driver for them to remain visible. Temperature never appears.

Yes. Those attributes reside inside child devices. So it is OK for them to not stay in the parent device.

By the driver logic after pressing 'Configure' button driver reads full state and gathers all the components. Using components list it spawns child devices accordingly. Basically one device type per one component type.

Temperature may come from separate temperature component or as a part of switch component. In either case it is forwarded to the separate temperature sensor child device.

1 Like
16

image
image1580×880 178 KB

17

Hmm.. It doesn't look like driver code got an update. 'HTTP query' was renamed to 'HTTP Async query'/'HTTP Sync query'. (aside from few added debug log entries) :thinking:

18

I had re-installed from the Bundle - after your last message I just re-installed the driver.....

image
image1573×789 192 KB

1 Like
19

Good clues for what to look for! High chance it is related to the 'sys' component parsing

A side of it system reports following components:

  • ble
  • cloud
  • mqtt
  • temperature -> will spawn child device
  • humidity -> will spawn child device
  • illuminance -> will spawn child device
  • switch -> will spawn two child devices (switch and temperature; might conflict with temperature device above)
  • input -> will spawn child device
  • sys
  • wifi

Conflicting temperature sensor will be the next issue to solve.

P.S.: The problem comes from unexpected property 'id' inside 'sys' component. It is not present in the documentation and has completely different meaning from other components (specifically those that may have multiple instances)

1 Like
20

I updated the driver code. 'sys' component together with other single-instance components should now avoid parsing 'id' for instance count calculation.