Any interest in Python 3?
11 views
Skip to first unread message
George Farris
Dec 15, 2017, 12:37:11 PM12/15/17
to pytom...@googlegroups.com
Hi all,
I'm wondering if there is any interest in Pytomation being ported to
Python 3 and Asyncio. I'm not sure I'm up to that second just because
of my python skills (I just don't put enough time into it) but porting
to Python 3 is probably doable.
I would like to add more hardware to Pytomation (ESP8266, RFlink etc)
but at this point unless we port it is probably a waste of time.
Thoughts?
Cheers
George
I'm wondering if there is any interest in Pytomation being ported to
Python 3 and Asyncio. I'm not sure I'm up to that second just because
of my python skills (I just don't put enough time into it) but porting
to Python 3 is probably doable.
I would like to add more hardware to Pytomation (ESP8266, RFlink etc)
but at this point unless we port it is probably a waste of time.
Thoughts?
Cheers
George
Message has been deleted
David
Dec 17, 2017, 5:50:38 AM12/17/17
to pytomation
I got started on the Python 3 port, in the Python3 branch. So far, I got the thing to load without error... It's not displaying my devices yet though.
It looks like we may be good with most of the dependencies. I'm not sure about the Belkin Wemo support though. It's dependent miranda.py does not seem to work in Python 3.
Also, gevent-websocket is in it's very early stages of Python 3 support; not all of its examples are working yet... and the last commit was in March. Although it does seem to be working in my tests so far, it still will need a lot more testing.
On Saturday, December 16, 2017 at 2:12:10 PM UTC-8, David wrote:
It looks like we may be good with most of the dependencies. I'm not sure about the Belkin Wemo support though. It's dependent miranda.py does not seem to work in Python 3.
Also, gevent-websocket is in it's very early stages of Python 3 support; not all of its examples are working yet... and the last commit was in March. Although it does seem to be working in my tests so far, it still will need a lot more testing.
On Saturday, December 16, 2017 at 2:12:10 PM UTC-8, David wrote:
Yeah, it really should be in Python 3. I looked into that before and at least one of the dependencies didn't have Python 3 support. That may have changed and definitely worth looking into again.Otherwise, the port shouldn't be too bad. There are a lot of string formats and such that need to be changed, but it's doable.Asyncio looks very interesting. I need to read up on it some more, before I can consider the design implications and come up with an estimated dev time... Then I can figure out the feasibility, given this project is developed during our spare time. I'll read up and think on it some more.
David
Dec 17, 2017, 3:15:05 PM12/17/17
to pytomation
Well, it turns out the devices were loading... mostly. But the web app was crashing if the thermostat didn't have a setpoint set. I think my thermostat isn't connected to WiFi right now, so it crashed (look at that in a bit). I fixed the bug, so it won't crash like that anymore and it loads fine now.
The Python 3 version loads much faster too.
The Python 3 version loads much faster too.
David
Dec 17, 2017, 8:14:23 PM12/17/17
to pytomation
And I just got OpenZwave working on it too... using the "experimental" 0.4.0 version of python-openzwave. Python 3 support is still in its infancy, but I know have all my devices running with it and it's testing very well -- running better than when in Python 2.
Please test and let me know how it works for you.
Please test and let me know how it works for you.
George Farris
Dec 17, 2017, 10:17:56 PM12/17/17
to pytom...@googlegroups.com
Wow, you completely rocked this, nice work David, I got as far as
cloning the git repo and was starting to look at replacing print ""
with print(""). Well done, I will give it a try when I get a chance.
I have a couple of thoughts:
1)
I looked into Home Assistant and liked that they were using Asyncio but
their way of writing drivers for devices is no way as clear and easy as
Pytomation from my point of view. Their documentation is lacking some
as well for such a mature project. Well I need to work on ours as well
but....
2)
I liked that they were using some third party stuff for Insteon, we
should maybe look at that but I don't necessarily agree that they seem
to automatically pull in the PIP repo for dependencies, in fact I
disagree as it can break things without notification. At least with
Pytomation we pull in a version and it will run.
3)
I would like to implement a few changes and additions to the standard
instance file specifically around multiple times in triggers etc. I
find it a bit limiting and drop into the mainloop for regular python
code which is one of the better ideas in Pytomation if you ask me.
4)
Would like to see a way to reload the instance without restarting. I
have stuff that runs only at Christmas so I either comment/uncomment
code and restart or have an IF statement, but then it requires
restarting as well, a bit messy.
5)
I added a WebButton device as follows:
from pytomation.devices import InterfaceDevice, State
from pytomation.interfaces import Command
class WebButton(InterfaceDevice):
STATES = [State.UNKNOWN, State.OFF, State.ON]
COMMANDS = [Command.ON, Command.OFF, Command.STATUS]
This way I can see just the controls I want in the web/app ui instead
of seeing a large list of generics.
We could call it something else UiButton or ????? I only did this in
my own local repo so far.
Other stuff will come back to me but that is it off the top of my head,
did add some changes to the time stuff about a year ago but it needs
expanding.
Oh yeah need to work on the HUE stuff some, I find it works great but
could use a few changes to fix status updates etc.
I will try run this up on a raspberry Pi and see how well it runs.
Cheers
George
> --
> You received this message because you are subscribed to the Google
> Groups "pytomation" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pytomation+...@googlegroups.com.
> To post to this group, send email to pytom...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
cloning the git repo and was starting to look at replacing print ""
with print(""). Well done, I will give it a try when I get a chance.
I have a couple of thoughts:
1)
I looked into Home Assistant and liked that they were using Asyncio but
their way of writing drivers for devices is no way as clear and easy as
Pytomation from my point of view. Their documentation is lacking some
as well for such a mature project. Well I need to work on ours as well
but....
2)
I liked that they were using some third party stuff for Insteon, we
should maybe look at that but I don't necessarily agree that they seem
to automatically pull in the PIP repo for dependencies, in fact I
disagree as it can break things without notification. At least with
Pytomation we pull in a version and it will run.
3)
I would like to implement a few changes and additions to the standard
instance file specifically around multiple times in triggers etc. I
find it a bit limiting and drop into the mainloop for regular python
code which is one of the better ideas in Pytomation if you ask me.
4)
Would like to see a way to reload the instance without restarting. I
have stuff that runs only at Christmas so I either comment/uncomment
code and restart or have an IF statement, but then it requires
restarting as well, a bit messy.
5)
I added a WebButton device as follows:
from pytomation.devices import InterfaceDevice, State
from pytomation.interfaces import Command
class WebButton(InterfaceDevice):
STATES = [State.UNKNOWN, State.OFF, State.ON]
COMMANDS = [Command.ON, Command.OFF, Command.STATUS]
This way I can see just the controls I want in the web/app ui instead
of seeing a large list of generics.
We could call it something else UiButton or ????? I only did this in
my own local repo so far.
Other stuff will come back to me but that is it off the top of my head,
did add some changes to the time stuff about a year ago but it needs
expanding.
Oh yeah need to work on the HUE stuff some, I find it works great but
could use a few changes to fix status updates etc.
I will try run this up on a raspberry Pi and see how well it runs.
Cheers
George
> You received this message because you are subscribed to the Google
> Groups "pytomation" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to pytomation+...@googlegroups.com.
> To post to this group, send email to pytom...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
David
Dec 19, 2017, 11:43:24 PM12/19/17
to pytomation
Thanks to the 2to3 script most of that work was done for me (love the robots we make).
1a) I briefly looked into Home Assistant, when my PLM died and I bought a HUB. I also thought Asyncio was pretty cool, while also seeing that the drivers aren't as easily written. That actually makes me think twice about Asyncio, since one of it's main purposes is to remove the clutter that comes from threaded code and organize the code better. I still haven't made a decision on Asyncio, but what I saw got me to make my decision to write the Pytomation Insteon Hub driver and continue to use Pytomation... perhaps with the additional "user" capability.
1b) Definitely on the same page with the documentation. I tend to not document everywhere it's needed... it is a "spare time" project, after all. A great example of this is I still have written the Python 3 dependencies (sorry):
sudo apt install python3-serial python3-apscheduler python3-pip
pip3 install ephem
pip3 install gevent-websocket
pip3 install wsaccel ujson
2) I actually started with the same insteonlocal library. But, in the end, Pytomation had better code in some places and I had to hack it so much to work with Pytomation all I was left with was most of the routine that translates the read byte-code to readable dictionary objects, but the interface actually only uses about 30-40 lines of that code. I still need to add some contributions to that library as I fixed some issues in that same routine... which is probably the cause of Home Assistant having a 5 second poll for the local HUB. On the plus side, I'm glad Home Assistant got rid of the ridiculously large security whole of a HUB Rest API that Insteon built (the code file isn't even in the master repo anymore, and that's a good thing). I have been strongly considering forking the insteonlocal library to allow the integration and then add the extremely small pieces to make the library universal form HUB to PLM (both devices use the same byte-codes, just a different protocol). OpenZwave does use a pip library... and it actually suffers a bit for it, by not having the same threaded queue system that's possible by returning before the hardware action actually happens, but still knowing when it does happen by initiated the proper read and getting the expected result.
3) Sounds great, I also would like to make some changes to the underlying system.
4) I also see the use in this. I think it might be easier to restart certain interfaces or devices (each has it's own thread to restart) vs the entire instance... but I'll look into restarting the instance. Before I do this, I need to implement the idea of user security, so not everyone can do this... which leads us to the next point.
5) I think it would be better to add user security to the system, with each user having it's own set's of devices and commands that it can access. Of course, a default admin user that that see everything would be automatically created with only what's listed in config.py. This way you can restrict users or even logged-in devices to certain actions. The user object could then be extended as an interface device, if we ever add an interface that can feed Pytomation user status (like when the user's phone is at home vs work). I think this is way less work than it sounds. I'll work on this on my day off this week. I'll shoot for having that ready before Christmas.
1a) I briefly looked into Home Assistant, when my PLM died and I bought a HUB. I also thought Asyncio was pretty cool, while also seeing that the drivers aren't as easily written. That actually makes me think twice about Asyncio, since one of it's main purposes is to remove the clutter that comes from threaded code and organize the code better. I still haven't made a decision on Asyncio, but what I saw got me to make my decision to write the Pytomation Insteon Hub driver and continue to use Pytomation... perhaps with the additional "user" capability.
1b) Definitely on the same page with the documentation. I tend to not document everywhere it's needed... it is a "spare time" project, after all. A great example of this is I still have written the Python 3 dependencies (sorry):
sudo apt install python3-serial python3-apscheduler python3-pip
pip3 install ephem
pip3 install gevent-websocket
pip3 install wsaccel ujson
2) I actually started with the same insteonlocal library. But, in the end, Pytomation had better code in some places and I had to hack it so much to work with Pytomation all I was left with was most of the routine that translates the read byte-code to readable dictionary objects, but the interface actually only uses about 30-40 lines of that code. I still need to add some contributions to that library as I fixed some issues in that same routine... which is probably the cause of Home Assistant having a 5 second poll for the local HUB. On the plus side, I'm glad Home Assistant got rid of the ridiculously large security whole of a HUB Rest API that Insteon built (the code file isn't even in the master repo anymore, and that's a good thing). I have been strongly considering forking the insteonlocal library to allow the integration and then add the extremely small pieces to make the library universal form HUB to PLM (both devices use the same byte-codes, just a different protocol). OpenZwave does use a pip library... and it actually suffers a bit for it, by not having the same threaded queue system that's possible by returning before the hardware action actually happens, but still knowing when it does happen by initiated the proper read and getting the expected result.
3) Sounds great, I also would like to make some changes to the underlying system.
4) I also see the use in this. I think it might be easier to restart certain interfaces or devices (each has it's own thread to restart) vs the entire instance... but I'll look into restarting the instance. Before I do this, I need to implement the idea of user security, so not everyone can do this... which leads us to the next point.
5) I think it would be better to add user security to the system, with each user having it's own set's of devices and commands that it can access. Of course, a default admin user that that see everything would be automatically created with only what's listed in config.py. This way you can restrict users or even logged-in devices to certain actions. The user object could then be extended as an interface device, if we ever add an interface that can feed Pytomation user status (like when the user's phone is at home vs work). I think this is way less work than it sounds. I'll work on this on my day off this week. I'll shoot for having that ready before Christmas.
Reply all
Reply to author
Forward
0 new messages