Krolken
commented
10 months ago Yes it is maintained 😄 But we are a bit busy with other stuff.
We aim to support all of our own use cases and our clients use cases. If there is no one requiring a feature we don't spend the time to implement it.
We also try to test of agains meters with the supported functionality. Since meters go through a test process it is the simplest way of verifying an implementation. I have some idea of making a github-action test runner that could run tests on meters we have connected in our lab, but we are not there yet.
Something we want to do soon is:
- Release the current version with the new composition API.
- Start implement association serialization to be able to load a configuration in the client and get static values like unit and scalar to give better results when your read profiles and data.
- Move this repo to the u9n organisation, same company just better to have it under the metering solution part
I took a quick look into your commits and it looks good. Some minor things that I don't like to write but that is just cosmetics. But we are as the newest release not longer fully open source. We use BUSL 1.1 to limit free loading of our library. Some feature we want to implement we previously started with in our closed source system as it would make it really simple for a competitor to make their own metering solution based on our code. Instead we release under BUSL and it is not allowed to use the code to make AMR systems.
So if we are going to merge in your changes I have to fix a CLA so that you agree that the license would be on your contributions too.
On the specifics sets of features I have to look more into them. You might be correct about the user_information. We almost exclusivly use encryption and the meters we send accepts the user_information anyway in an unencrypted context. I would need a meter that is not accepting it to verif and figure out how it is best integrated in the library.
Do you have a use case for set-with-blocks? On what would you like to set a lot of data? I need to test agains a meter to verify the implementation.
isidroas
I don't see much movement in recent months. I like this project because you see mastery in Python and a depth knowledge of the standard. Plus, the implementation is enjoyable, not only for what it does, but also for how it does it
If it is maintained, I could do the effort of creating various merge requests for the following commits in my fork and further contribute. Some of those changes are: