rewrite

[Jan200101]

ShellyPy was originally written quite hastily without the expectation of API revisions or similar.

The idea afterwards was to write a C library for which Python bindings could be written that abstract the concepts, but the inconsistencies of the Gen 1 API have drowned any desire to actually implement that.

Now ShellyPy has developed a bit of cruft based on assumptions that are no longer true or were never true to begin with.

Rewriting the entire library from scratch with support for multiple different backends (direct http, mqtt, CoIoT, cloud) may be better than piling ontop of an already unstable foundation.

[h3tz]

like the idea but can not support the amount of work needed.

[Jan200101]

all work-in-progress rewrite stuff will appear on the wip/rewrite branch (at the moment all it can do is Gen1 light toggling)

Once I manage to get all my local Shelly devices working under it using at least one backend I'll merge all the WIP commits into a singular rewrite one and start a dev branch under it.

[h3tz]

i just have a single shelly plug device so I am limited doing testing (except code review, architecture and stuff like that)

[h3tz]

What do you think about Websockets as the backend or is this meant by http backend to use MQTT?

[Jan200101]

backend talks about the different ways an API can be used to talk to the devices.

For Gen1 that would be http, MQTT and CoIoT(based on CoAP).
The user of this library can then eiher choose to use the default backend (currently http, possibly CoIoT in the future) or pick one to fit their specific needs (with mqtt the device would announce when something changed allowing the library to change its state)

I am not aware of any Shelly devices that support Websockets

[h3tz]

any update?

[h3tz]

any update ? dead?

[Jan200101]

Its happening but slowly.

• The entire typing substructure was replaced with base implementations that need to be adapted by the relevant backends
• HTTP Gen 1 is implemented and needs testing (I own various Gen Shelly devices, so this shouldn't be too troublesome)
  • MQTT needs to connect to a broker and would benefit from a retooling to async
  • CoIoT requires a modified CoAP implementation, which does not yet exist for Python
• Gen 2 will be implemented once HTTP Gen 1 has been tested
• Generic Generation detection and automatic backend selector needs to be implemented
• detection over mDNS needs to be implemented (should this be optional?)

Going further I have been thinking about if this library could benefit from async or callbacks, I'll have to see if either makes sense and how to implement them properly

[Jan200101]

long live rewrite!

• Gen 1 and Gen 2 work over Rest and JSON-RPC respectively, both supporting authorization.
• Generic Generation detection over the shared /shelly endpoint has been implemented
• absolutely 0 required dependencies

Its "working" but its not finished.

I currently don't have an MQTT setup, but this is worth looking into since it allows active tracking.

Cloud support has been dropped for now, it would add complexity that would hinder the completion of an MVP.

mDNS is coming as an optional feature with a singular dependency on zeroconf that needs to be opted into using at install time and can only be used via a specific class.

[h3tz]

any updates?