cpyarger / Home-Assistant-Addons

A hass.io addon for a software defined radio tuned to listen for Utility Meter RF transmissions and republish the data via Home Assistant's API
MIT License
9 stars 4 forks source link

User Questions #12

Closed SpaceCadetRick closed 2 years ago

SpaceCadetRick commented 2 years ago

I started using your SDR Meter Reader add-on today and had a couple questions. I first ran it in msgType: all and then narrowed it down to msgType: scm before finding the ID that matched my gas meter however as a result I now have all of the sensor.xxxxxxxx data for all of the different meters that I picked up. How do I remove those?

My second question is how do I add a second meter id to watch for? When I add a second id separated by a comma it tells me "xxxxxxxxx, " is not a valid id and if I try to add each one in quotes it just deletes the second number.

Edit. After posting I tried it like this "ids: 1234,5678" and so far I've been getting readings for 1234, my gas meter, but my water meter, 5678, hasn't popped up yet though it may only wake up when they come around every month to read it.

pasyn commented 2 years ago

Any extra sensor IDs should be dumped on a reboot of home assistant because these sensors are saved as states instead of true entities.

Make sure all is set for msgtype as water and electric tend to use different protocols. You can also turn on the debug switch and watch the log to see if the sdr is picking up the water meter.

SpaceCadetRick commented 2 years ago

With the default 15s duration followed by 30s pause would a reading sent while paused get missed?

pasyn commented 2 years ago

Possibly. I'll have to look back through the code to see how it works. 120 for duration and 30 for pause time works well for me.

SpaceCadetRick commented 2 years ago

I'm having another issue, the entity created is just reporting a number without any of the unit_of_measurement or state_class attributes set. I'm able to add these using developer tools but they get overwritten the next time the entity updates. Screenshot_20220601-164958

pasyn commented 2 years ago

For some reason the addon is not parsing the sdr data correctly. Please turn on debug mode and post the json output from the log relevant to that meter.

SpaceCadetRick commented 2 years ago

s6-rc: info: service s6rc-oneshot-runner: starting s6-rc: info: service s6rc-oneshot-runner successfully started s6-rc: info: service fix-attrs: starting s6-rc: info: service fix-attrs successfully started s6-rc: info: service legacy-cont-init: starting s6-rc: info: service legacy-cont-init successfully started s6-rc: info: service legacy-services: starting s6-rc: info: service legacy-services successfully started Starting RTLAMR with parameters: AMR Message Type = scm AMR Device IDs = 47795513,71864109 Time Between Readings = 30 Duration = 120 Electric Unit of measurement = Wh Gas Unit of measurement = ft³ Water Unit of measurement = gal SCM PLUS GAS DIVISOR = 1 Debug is true Found 1 device(s): 0: Realtek, RTL2838UHIDIR, SN: 00000001 Using device 0: Generic RTL2832U OEM Found Rafael Micro R820T tuner [R82XX] PLL not locked! Tuned to 100000000 Hz. listening... Allocating 15 zero-copy buffers 17:36:58.209187 decode.go:45: CenterFreq: 912600155 17:36:58.209935 decode.go:46: SampleRate: 2359296 17:36:58.210002 decode.go:47: DataRate: 32768 17:36:58.210017 decode.go:48: ChipLength: 72 17:36:58.210030 decode.go:49: PreambleSymbols: 21 17:36:58.210042 decode.go:50: PreambleLength: 3024 17:36:58.210081 decode.go:51: PacketSymbols: 96 17:36:58.210098 decode.go:52: PacketLength: 13824 17:36:58.210116 decode.go:59: Protocols: scm 17:36:58.210129 decode.go:60: Preambles: 111110010101001100000 17:36:58.210167 main.go:124: GainCount: 29 {"Time":"2022-06-01T17:37:01.42453931-06:00","Offset":0,"Length":0,"Type":"SCM","Message":{"ID":47795513,"Type":12,"TamperPhy":0,"TamperEnc":0,"Consumption":799708,"ChecksumVal":37283}} 200 {"Time":"2022-06-01T17:37:47.429065053-06:00","Offset":0,"Length":0,"Type":"SCM","Message":{"ID":47795513,"Type":12,"TamperPhy":0,"TamperEnc":0,"Consumption":799708,"ChecksumVal":37283}} 200 {"Time":"2022-06-01T17:38:01.422920368-06:00","Offset":0,"Length":0,"Type":"SCM","Message":{"ID":47795513,"Type":12,"TamperPhy":0,"TamperEnc":0,"Consumption":799708,"ChecksumVal":37283}} 200 {"Time":"2022-06-01T17:38:16.42275069-06:00","Offset":0,"Length":0,"Type":"SCM","Message":{"ID":47795513,"Type":12,"TamperPhy":0,"TamperEnc":0,"Consumption":799708,"ChecksumVal":37283}} 200

pasyn commented 2 years ago

Scm type 12 is not accounted for. Is that a gas meter?

SpaceCadetRick commented 2 years ago

Yea, as certain as I can be. The ID number matches and the consumption has matched the meter reading on multiple occasions.

pasyn commented 2 years ago

I pushed an update that should resolve your problem. Let me know if it works.

SpaceCadetRick commented 2 years ago

Yep, that worked, thanks! Screenshot_20220601-193520

pasyn commented 2 years ago

Excellent! I'm going to close this issue. Feel free to open another if you run into any other problems.

cpyarger commented 2 years ago

@pasyn just an FYI, 12 was not included because it can be either a gas or electric meter we may want to keep that in mind if we get an electric meter of type 12 https://github.com/bemasher/rtlamr/blob/master/meters.md

pasyn commented 2 years ago

Thank you for pointing that out. That could make things messy. Looking at meters.csv in the rtlamr repository, the Schlumberger CENTRON OOK RF is the only electric meter with type 12. Most of the meters with type 12 are gas. I think gas should be the default for 12 given that there is only one exception. Do you think it would be possible to identify the Schlumberger meter based on the ID? I've noticed that many meters have the same first three digits. Maybe this prefix could be linked to a manufacturer.

cpyarger commented 2 years ago

I agree about gas being the default.

I am not sure, does it use the same message type, if its a difference between scm and scm+ maybe we can do the determination there. Currently we don't really set any variables based on that message type change and just run both through the scmplus parse function

pasyn commented 2 years ago

That's a good idea. I will research further.