Porting pyHS100 to MicroPyton

[nadigo]

Hi,

I'm trying to port part of the library pyHS100 to micropython, the idea is to be able to run it on an embedded wifi IOT device as a mobile on/off switch (for a start).

Any idea if should this be a fork ?

N

[kirichkov]

I'm not knowledgable enough of MicroPython (or Python for that matter) but If you can adapt the micropython-based code to work with the existing codebase I think we'll be more than happy to accept your merge.

The point here is that this library should remain functional as it is, if there's a way to safely detect micropython and exclude parts of the code - then this will work, if you have to change the code so it runs only MicroPython - then a "fork" is the way to go, although I think starting from scratch will be much easier for you then trying to rework the current code with all its complexities and features.

[nadigo]

you might be right, I'll try to see where I get with native micropython and see what's the best strategy.

On Mon, Aug 7, 2017 at 9:18 AM, Georgi Kirichkov notifications@github.com wrote:

I'm not knowledgable enough of MicroPython (or Python for that matter) but If you can adapt the micropython-based code to work with the existing codebase I think we'll be more than happy to accept your merge.

The point here is that this library should remain functional as it is, if there's a way to safely detect micropython and exclude parts of the code - then this will work, if you have to change the code so it runs only MicroPython - then a "fork" is the way to go, although I think starting from scratch will be much easier for you then trying to rework the current code with all its complexities and features.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GadgetReactor/pyHS100/issues/78#issuecomment-320660693, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0MhWJ0Q83RAJKsWGgScaA0Vu6tj3fSks5sVw6cgaJpZM4Ou7Ll .

[rytilahti]

What kind of errors are you getting on micropython / what parts of the code are not compatible with it?

[nadigo]

the issue is missing few dependencies, I'll post it soon

On Mon, Aug 7, 2017 at 10:45 AM, Teemu R. notifications@github.com wrote:

What kind of errors are you getting on micropython / what parts of the code are not compatible with it?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GadgetReactor/pyHS100/issues/78#issuecomment-320683816, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0MhUBQcydBuVstyECQVEMR_cSqBIymks5sVyLxgaJpZM4Ou7Ll .

[rytilahti]

click and click-datetime are only necessary for the client tool to function, the library itself does not depend on them. So if that's the only problem, it should (hopefully) easy to patch setup.py to have it not to depend on those on micropython and create a simple(r) control script, if wanted.

[nadigo]

I'll try with these ones and post some progress, my idea is to set a wifi switch / trigger based on the Espressif ESP32 chipset or similar - There are many Amazon Dash button hacks are trying to do the same, I made one using a raspberry pi zero and 'arp' catchup, so i hope I can port to micropython and release it as a battery operated wifi switch

On Mon, Aug 7, 2017 at 11:39 AM, Teemu R. notifications@github.com wrote:

click and click-datetime are only necessary for the client tool to function, the library itself does not depend on them. So if that's the only problem, it should (hopefully) easy to patch setup.py to have it not to depend on those on micropython and create a simple(r) control script, if wanted.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GadgetReactor/pyHS100/issues/78#issuecomment-320699068, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0MhTjBoStgB-zsOZyNTorsKvke4XWHks5sVy-zgaJpZM4Ou7Ll .

[rytilahti]

Ok, sounds fair enough. For your usecase you will not definitely need a full-blown client application, so simply remove those dependencies for testing and create a simple script using the library directly to see if there are some pieces of code not working without modifications on micropython. PR to fix any encountered issues is appreciated :-)

[nadigo]

I implemented the client protocol using the TP servers, I assume it's basically sending the same Jason payload over HTTPS directly to the local device (without the need for registration step) - right ?

{ "method": "passthrough", "params": { "deviceId": "XXXXXXXXXXXXXXXX", "requestData": "{\"system\":{\"set_relay_state\":{\"state\":1}}}" } }

On Mon, Aug 7, 2017 at 2:29 PM, Teemu R. notifications@github.com wrote:

Ok, sounds fair enough. For your usecase you will not definitely need a full-blown client application, so simply remove those dependencies for testing and create a simple script using the library directly to see if there are some pieces of code not working without modifications on micropython. PR to fix any encountered issues is appreciated :-)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GadgetReactor/pyHS100/issues/78#issuecomment-320743272, or mute the thread https://github.com/notifications/unsubscribe-auth/AF0MhaUn3Ox9kPoBSgQESdVmREdiagMjks5sV1eCgaJpZM4Ou7Ll .

[jeffsf]

While I'm excited about the possibility of using these libraries on something as brain-dead as an ESP8266, I would not want to have added complexity in the day-to-day branch.

If the goal is a battery-operated, WiFi-connected remote, I would either

• Use your phone (if you trust TP-Link's security, which I don't)
• Use something like an ESP8266 and MQTT-S with a broker and a client that responds to the button-presses on the remote and controls the TP-Link devices

The latter approach has the advantages of being able to control from outside of WiFi range, assuming you have proper secure access from the outside to/from your MQTT-S broker/client (however you may have chosen to host it).

[rytilahti]

The question is whether this would add any unnecessary complexity to the code, as it may well be our code is compatible already. I glanced on the differences between micropython and cpython on micropython's website and from the looks of it we should not have incompatible code, but the easiest way to check it would be simply to try it out and see if it works.

edit: taking another look into it, some modules are prefixed with 'u' making the code incompatible without having a wrapper for those, I suppose.

[kirichkov]

I'm against adding too many complexities as well. What I have in mind is to accept it if there are a few library differences that can be nicely isolated in the setup.py or something similar and transparent. If the current code will be riddled with if-then-elses to handle uPython I am against it, as it will make the code very hard to maintain and change while preserving the uPython integration, unless the uPython also has full test coverage, which even our current code does not have.

[rytilahti]

Closing as stale, if someone wants to work on this please open a PR.