Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Smilics interfacer in v2.1.0 #51

Open
TrystanLea opened this issue Feb 19, 2018 · 2 comments
Open

Smilics interfacer in v2.1.0 #51

TrystanLea opened this issue Feb 19, 2018 · 2 comments

Comments

@TrystanLea
Copy link
Member

TrystanLea commented Feb 19, 2018

Hello @K0den, While working on a number of changes to emonhub to fix an issue with the http buffering and to re-factor the code closer to how @pb66 intended it to work back in the experimental branch. I got a bit stuck working out how to re-factor your Smilics interfacer. Could you explain to me how it is meant to work?

Given that the interfacer is running in its own thread (a bug relating to this was fixed last July). Is there any need for starting a server on a second thread?

Ideally the interfacer should not overwrite the run method if it is avoidable. Data should be read in with the read method which should be used instead of the _process_rx method that you implement.

Perhaps if I understood better how the Smilics interfacer is meant to work I could help refactor the code?

I have temporarily placed the smilics interfacer in a folder called tmp in the interfacer folder here https://github.com/openenergymonitor/emonhub/blob/emon-pi/src/interfacers/tmp/EmonHubSmilicsInterfacer.py

@bwduncan
Copy link
Contributor

bwduncan commented Jan 6, 2020

@TrystanLea I don't believe this code even works. It calls _process_rx twice with two different objects (dict and EmonHubCargo) so one of them must return None which causes the data to simply be dropped. For this reason I can't port this interfacer to Python3 and the reasons you mention above. Given that, and this issue has remained open for almost 2 years, I think we have to just drop this code. It's a shame because it looks like a clever bit of kit.

@TrystanLea
Copy link
Member Author

Thanks @bwduncan I agree. Perhaps placing in a folder called archived with a readme mentioning that code needs updating to work with latest version of emonhub might open it out to anyone interested and able to test to get it back up and running agin?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants