Multiple Protocols per Invocation

[jepler]

I happen to have a supported electric meter and water meter, but it appears that one sends IDM messages and the other SCM messages. Is it only a software limitation that the two distinct message types can't be received and decoded by a single rtlamr instance?

Right now my workaround is to invoke it in single shot mode first for one message type and then the other, and that does work so woo

[bemasher]

It's primarily a software limitation at the moment. It is theoretically possible but messy with the way things are structured now. It is also a matter of performance, you almost certainly won't be able to do this on something like a Raspberry Pi.

I'll do some investigation into how easily this could be done.

[jepler]

Indeed, my solution over in pull request #40 for scm+ism is taking ~100% of one CPU thread on the Odroid U3 where it is running--so close to 100% that now I wonder if it isn't dropping packets to boot. I didn't think to look at CPU usage when running in just scm or just ism mode, but I can see that splitting the work in the wrong place would double resource usage.

[bemasher]

It's also a matter of coordinating the two receivers. One solution I've considered is building a multiplexed rtl_tcp clone in go, you get all the same features, and the ability to connect multiple clients who will all receive the same data.

[parkerlreed]

This is currently working for me using https://github.com/simonyiszk/rtl_mus

Top right is rtlamr with default scm and bottom right is idm. Both are pointed to the 7373 port created by rtl_mus. I receive messages on both.

This is using a single receiver.

EDIT: Just realized this post was more about receiving both message types in one session. Saw multiplex mentioned.

I notice this does allow for both rtlamr instances to run at once (second just freezes if I try without rtl_mus)

[ekrohn]

rtl_mus is an excellent suggestion. I have a PV installation with production meter sending SCM and IDM packets and a net meter (consumption-production) sending SCM+ packets. rtl_mus lets me collect data from both of my meters and it lets me fire up additional rtlamr clients to explore other traffic without disrupting the first two.

[bemasher]

I've just committed multi-protocol support to a new feature branch. If anyone would be willing to test this, let me know how it goes. You can install the new branch as follows:

git fetch
git checkout multiprotocol
go install -v .
rtlamr -msgtype=all

This feature will require some documentation before it can be included in the next release.

[ekrohn]

cypherstream, Odds are you built master, rather than the multiprotocol branch. If so, when you run rtlamr -help you see: -msgtype=scm: message type to receive: scm, scm+, idm, r900 and r900bcd rather than the newer and longer: -msgtype=scm: comma-separated list of message types to receive: all, scm, scm+ , idm, netidm, r900 and r900bcd Douglas, Is there a reason -msgtype all does not include netidm? At least that's what this go-ignorant programmer sees in main.go.

[bemasher]

@ekrohn netidm is not included in all because it is the same preamble/length/checksum as idm, it only interprets the contents of the packet differently. The idea behind all is that it should at least show messages from each protocol, and users should only be using it for discovery. Once they know what is being transmitted, they should select the appropriate message types based on their meter(s). This is the same reason r900bcd isn't included in all.

[bemasher]

@cypherstream you may want to try using git clone instead of go get.

From a Git Bash terminal:

cd %GOPATH%/github.com/bemasher
rm -rf rtlamr
git clone https://github.com/bemasher/rtlamr.git
cd rtlamr
git checkout multiprotocol
go install -v .

[cypherstream]

Ok never mind my last few posts. Quite a few people had that issue. Found my way through it from a post over at stackexchange. It was for unix based system but basically an environment variable called GOBIN needed to be set. I did this and then it was able to build properly.

I am now able to run it with the -msgtype=all so I can discover what type of protocols I am finding in our area. We've had remote read water and gas meters and just yesterday they put on an Itron OpenWay IP Mesh digital electric meter. I wanted the ability to search through all message types to determine which devices used which protocols.

[bemasher]

@cypherstream I'm going to hide a few of your posts between your last one and this one to keep the issue on topic.

[bemasher]

Preliminary support has been added in release v0.9.0