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

Alternative methods of reading data #66

Open
yurgh opened this issue Nov 23, 2021 · 3 comments
Open

Alternative methods of reading data #66

yurgh opened this issue Nov 23, 2021 · 3 comments

Comments

@yurgh
Copy link

yurgh commented Nov 23, 2021

Not an issue, but a suggestion:

I've modified my Tibber Pulse to send data to my MQTT-server (explained here: https://github.com/iotux/ElWiz#oppsett-av-pulse ). Unfortunately that project doesn't support my Kamstrup Omnipower 1 Phase Direct meter.
However; with my limited Python skills I've been unable to modify hass-AMS to use the binary data from the MQTT server instead of reading from serial.

So; any plans on adding alternative input methods your component?
I vote for MQTT-support, but could be anything that delivers binary data! :-)

@sandos
Copy link
Contributor

sandos commented Nov 23, 2021

This method should work for this?

https://www.zigbee2mqtt.io/advanced/remote-adapter/connect_to_a_remote_adapter.html#_1-install-ser2net

Hmm, ok, it does look like zigbee2mqtt has some specific support for a tcp-protocol for the serial port, so likely some work to get it to work.

@Hellowlol
Copy link
Contributor

Hellowlol commented Nov 23, 2021

Tried using https://github.com/toreamun/amshan-homeassistant ?

I fixed this by using a rpi that reads the serial (it has been running since ha 0.7 or so) and statestream to get the info to my real ha install

@yurgh
Copy link
Author

yurgh commented Nov 24, 2021

Thanks for suggestions!

I was able to hack the parser to match what my meter is sending. The meter suddenly changed the format, thus all my sensors just reported bogus values. Seems to have started sending more bytes, because the offset for some of the values was changed by four. I guess thats what you get for hardcoding offsets instead of looking for the OBIS-codes and their corresponding data... :P

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

No branches or pull requests

3 participants