Can't read multi-word values

[tjhowse]

It would be nice to support 32/64 bit numbers and fixed-length strings.

[tjhowse]

Also types: int16, uint16, int32, uint32, int64, uint64, String(16), String(32), etc.

[tjhowse]

For starters I think the best way to handle this would be to add int32, uint32, int64 and uint64 to the allowed types list, and have the mqtt_interface.__init__ method derive the length and add it as a key to the registers map. Then we'd need to call self._mb.add_monitor_register for the required additional addresses past the starting address in the YAML entry. Then mqtt_interface.poll can use the length field to stitch together a few register values into the multi-word value before doing the type conversion/scaling/etc. Then we'd need a few simple unit tests for reading/writing each new type.

[icypete]

I have written some code that adds int32, uint32, int64 and uint64 types. Tested with SG8K-D and looks to be working well. Didn't break anything and signed 32bit values like Energy Meter Power work now;

Code is minimal. I haven't used github much but when I work out making a branch I'll add the code for review...

[icypete]

here are the code changes I made to add multi byte support.

i had to comment out one line for the masking, but it should be easliy fixed

multi byte support.zip

[icypete]

ok, i have fixed up the masking I commented out in the code i provided above. this zip file read's multi-byte addresses and lets masks work still.

multi byte support - with masks.zip

[tjhowse]

Thanks very much! This is awesome! I'll set aside some time this weekend to get this merged in.

I'm happy to do it on my end, but would you like a hand walking through the github pull request process? This way your profile will show you as a contributor to this repo, and it'll be your commit to the main branch containing the changes rather than mine. Up to you!

[icypete]

cool, no problem if you want to merge any of that code yourself. this is a cool little project though and i'd love to be able to commit code. i'll read up on how to do that (if you have a github-101 cheat sheet let me know)

[tjhowse]

Here's a decent guide to the overall idea behind the pull-request-based workflow: https://www.atlassian.com/git/tutorials/making-a-pull-request

The short version: You "fork" a repository to create a "downstream" copy of it under your own github account. You clone that fork to your local machine, make your changes and then push them back up to your github fork. You can then raise a request to pull the changes from your fork back into the "upstream" fork. The maintainer (me, in this case) and the contributor (you) have a discussion about the change in the pull request web interface until both parties are happy with the changes. At this point the maintainer merges the pull request into the upstream fork.

[icypete]

nice, seems straight forward. I have cloned and forked the repository. i'll have a go at submitting a pull request today.

[tjhowse]

Closed by #29