Added setup.py for easy pip installation

[retrodaredevil]

This pull request basically moves most of the files into the pymate folder so it can be treated like its own module. I wanted to be able to do something like pip2 install git+https://github.com/jorticus/pymate.git so I wouldn't have to fork it and make my own changes. So I basically forked this so you can install it with pip easily. (Run python -m pip install git+https://github.com/retrodaredevil/pymate.git) Eventually you could make this an official module so all you'd have to do is python -m pip install pymate.

I know this is a huge change, so don't feel like you have to accept this. I mostly just did this so it'd be easier for me to use and import.

Some things like srv1, srv2, plot.py, readout.py, scan,py I didn't move into the pymate folder because they were basically their own individual programs and not really part of the API.

srv1 and srv2 now have __init__.py so they can be treated as their own packages. This means that to run the files inside there you have to do python -m srv1.<file_name>. Of course, if you install pymate to your system you could just import it from there, but this makes it so you can use srv1 and srv2 without it actually being installed on your system.

I made a lot of changes to the files in and outside of pymate to use relative imports and some absolute imports. I added a .gitignore as well. I also added requirements.txt to srv1 and srv2 to make it easier for people to know what they need to have installed in the future. The only problem I came across is when Tkinter was used in plot.py. On Ubuntu you have to have python-tk installed so just running pip2 install -r requirements wouldn't install that, which is why there isn't a requirements.txt in the root folder.

The only changes I made that may actually affect the program is in scan.py on line 42. It had exit on it when it really should have been exit(). So if this isn't accepted you might want to fix that.

I might end up converting the code to python3 eventually if I find myself using this a lot. Disclaimer: I didn't actually test this since I don't have any Outback devices to test it with. In around 3 weeks I might have access to a MX, but I'm not sure. I did however, import each file in pymate to make sure there aren't any Syntax or Import errors.

I've been working on something similar to this for almost 2 years now: https://github.com/wildmountainfarms/solarthing. Instead of simulating one of the devices, it reads stuff from the serial port on the Mate. I've learned a bunch of stuff from looking at your code and if you're interested in how I parse status packets (like you do in matecom.py) you can look at my code to see how to parse FX packets if that's useful to you. It looks like the way you parse the packets is a lot simpler than how I do it.

[jorticus]

Wow thanks for the PR! And thanks for setting it up for pip - I'll figure out how to publish it there as well...

I've tested the matenet stuff with my Arduino emulator and it all looks good, though I wasn't able to test the matecom.py stuff as I don't have a MATE. Don't worry about the plot.py demo too much - it was just a quick experiment to get things up and running and I don't use it anymore. Instead I use srv1/2 to pipe it to a server and display it with Grafana.

I'll go ahead and merge it in 🙂

(PS. nice project! I don't do Java myself, but it looks pretty well structured)

[retrodaredevil]

Thanks for merging.

I didn't think about making an arduino program to emulate the serial port. The only thing I've done is create a virtual_mate.sh file. I just found your https://github.com/jorticus/uMATE repo. That will definitely help me while testing stuff.

If I make another PR, it will probably be to generalize serial port input. It's nice that your library makes it super easy to connect to serial ports, but for testing I think it'd be much easier to be able to do the same thing with just stdin. I know that's worked well for me while testing my library. Ex: ./virtual_script.sh | <run program> instead of just <run program.

EDIT: I was looking at the uMATE repo and I now see that the readme says that I cannot use an Arduino Uno for that. I'll have to figure out another way to test it. Maybe using 16 bit characters with stdin and stdout? Let me know if you have any good ideas.

[jorticus]

Thanks again for adding this PR. I have now published it to PyPi as pymate with the latest code.

FYI I have also refactored the code to support multiple kinds of serial port (well at least for the main pymate library). It supports emulated-9bit-serial (as before) & PJON-framed serial (for use with uMATE), but you could in theory use other interfaces like TCP/IP or stdin/out.

As for using an Uno, unfortunately it's probably not going to be possible as the MATE requires 9 bit data which will interfere with the PC terminal. Though perhaps you could get away with using software serial...

[retrodaredevil]

The serial improvements look pretty good. It looks like those changes would make it a lot easier to test out. If I do end up using this, I probably won't use an Arduino Uno and I might just try and test it through stdin/stdout.

I'm not sure if I'll end up using pymate this summer. I planned on it last summer, but we ended up just plugging our second MX into port 4 of the Hub4 which we still had open. I'm still debating whether it'd be worth it to try and replace the Mate. The setup is working pretty well right now with status packets. However, status packets can only get us so far. Some extra data would be nice, especially for the FXs and their timers when charging the batteries from AC power.

If only we had a Hub10, then we could keep using the Mate and also emulate a second Mate with pymate. Gosh, why does a Hub10 have to be $300...