Add support for Shelly devices using a password in their UI
Component
Edge
Description
Currently no connection can be established to Shelly Switches/Meters if they use a password in their Web UI. It would be great to support devices using a UI password, cf: #3204. Shelly API doc: https://shelly-api-docs.shelly.cloud/gen2/
Theoretically this would be possible. But since Version 2 of Shelly Devices they switched to HTTP Digest Authentication so it would be a lets call it "Nightmare" to add this Extensive Authentication to these Simple - yet small Device. we could indeed create a Hint for the User, that Password should be switched off to use it with OpenEMS - i already Implemented and tested a Version with Authentication and it works - but as is said it would be a VERY hard change in every Shelly.
I will create a PR where we inform the User to switch off his Auth if he wants to use it with OpenEMS for now as we can get this info from the /shelly endpoint:
{"name":null,"id":"shellyplus1pm-80646fe34998","mac":"80646FE34998","slot":0,"model":"SNSW-001P16EU","gen":2,"fw_id":"20250520-083721/1.6.2-gc8a76e2","ver":"1.6.2","app":"Plus1PM","auth_en":true,"auth_domain":"shellyplus1pm-80646fe34998"}
Whats your Opinion on this @sfeilmeier ? We could create a new "Fault" or "Warning" channel on this case?
Yes, everything in that direction is welcome! Ideally we would unify these State-Channels in a common Nature for all Shelly implementations.
What about #3203. Should I merge it already or are you going to touch it again?
Yes, everything in that direction is welcome! Ideally we would unify these State-Channels in a common Nature for all Shelly implementations.
What about #3203. Should I merge it already or are you going to touch it again?
Well basically as stated in here
I would not inform the User in the Generic Fault but create a seperate Channel for this (as this is not a General Fault in means). But unfortunately i can not edit this PR as it is Provided from @sjjh
I can simply close #3203 if you want.
I can simply close #3203 if you want.
As I suggested i guess you do not need to close it, just add another "check" for "isPasswordSet" or something like this, which sets a channel to inform the user about the "wrong" usage or configuration of the Shelly device - should be global though..
@sfeilmeier i created a new PR addressing my suggetions and your approach unifying these State-Channels in a common Nature for all Shelly implementations.
@Sn0w3y looking at your new PR #3248 I should close my PR (or revert the commit at least) now? I will/would need some support in adding the check for "isPasswordSet" you mentioned. Would this go into https://github.com/OpenEMS/openems/blob/7646a78051b6d3ed0e4daba390c7a34cff3371d9/io.openems.edge.io.shelly/src/io/openems/edge/io/shelly/shellypro3em/IoShellyPro3EmImpl.java#L154 by creating a new var for the password state, reading the response (probably the shelly docs will give me an idea how the parameter is named) and then setting the channel?
@Sn0w3y looking at your new PR #3248 I should close my PR (or revert the commit at least) now? I will/would need some support in adding the check for "isPasswordSet" you mentioned. Would this go into https://github.com/OpenEMS/openems/blob/7646a78051b6d3ed0e4daba390c7a34cff3371d9/io.openems.edge.io.shelly/src/io/openems/edge/io/shelly/shellypro3em/IoShellyPro3EmImpl.java#L154 by creating a new var for the password state, reading the response (probably the shelly docs will give me an idea how the parameter is named) and then setting the channel?
Hi,
in my PR everything regarding the isPasswordSet is already implemented - we need to wait for @sfeilmeier to Review/Merge.
In the meantime you could also test the new Implementation.
in my PR everything regarding the isPasswordSet is already implemented
Ok, then I've closed my PR.
In the meantime you could also test the new Implementation.
I'll happily test, once it appears in the develop docker image.
This issue has been automatically marked as stale due to inactivity
If it is still relevant, please comment or update the issue. Otherwise, it will be automatically closed in 14 days.
For further assistance, visit the OpenEMS Community Forum.
cf https://github.com/OpenEMS/openems/pull/3248