This plugin makes use of the rtlamr software and a USB Software Defined Radio to read standard data packets from some smart meter devices. Depending on your meter and it’s configuration you may be able to receive gas, water and Electric meters. Possibly others as well. It may not be possible to know for sure if it’s going to work for your meter without experimenting. Many meters use an encrypted protocol or a mesh network for sending their information which won’t work with this software. I can read several gas meters in the neighborhood here and have received a few packets that claim to be electric and water meters but they don’t transmit more than once or twice a day and so it’s harder to catch them and figure out if that is really my meter or not. So while I can get about 90 second granularity from my gas meter I only receive a single packet a day with a simple usage amount from my electric and water meter. I know that they send more data than that but I haven’t found it yet. Please see the link to the github repository and wiki about the rtlamr software for more info on what meter versions are known to work and what kind of packets they send.
This plugin is in an unfinished beta state. Not all meter messages are supported yet as there aren’t any for me to receive to work from and other peoples examples are hard to come by. If you need to use a different protocol than the SCM that is turned on by default please go ahead and enable it. Any data from a protocol other than SCM will be logged. Please collect those entries and send them to me to make it possible to support the other message types.
The hardware requirements are the same as those for the rtl_433 plugin. Please see that page for more information on supported radios.
As with the rtl_433 plugin I recommend SDR radios from the rtl-sdr blog folks. Their radios are available on Amazon and other places as well but make sure you’re getting the real thing and not one of the clones or cheaper brands or it will significantly affect your range or even the ability to receive anything at all. I’ve got 1 of the cheaper ones from testing that is recognized but cannot receive anything in the needed range for any of these projects at all and another that will only receive if the transmitter is within about 2 feet of the device. Not worth cheaping out to save $20 that you’re just going to have to spend again anyway when it doesn’t work at all. That being said the multi-hundred dollar devices like the HackRF are not necessary.
If you wish to connect more than one SDR to the same machine you will need to use the rtl_eeprom program which is included with the rtl_433 plugin linked to above in order to give them unique serial numbers.
The rtlamr plugin also supports using a raspberry pi as a remote host just like the rtl_433 plugin. Please follow the same instructions on the rtl_433 page for installing the rtl_433 software on the raspberry pi. Since the rtlamr instance runs on the XTension machine and connects to the radio over the local network it is not necessary to also install rtlamr on the pi. Just follow the rtl_433 install on the pi and you’ll have all the software there you need.
By default rtlamr operates in the 900Mhz band and so will need different antennas than the rtl_433 software in order to reliably receive the information.
You can also use a wide band or specific amplifier to increase your range if you wish or need to. There is also some discussion of this on the rtl_433 page.
Once the radio is connected to the Mac you can visit the Interface List window and click the “New Interface” button. Select “Smart Meter Receiver” from the Device popup.
Connection Type: If the radio is connected to the local mac select “Local USB” and then skip over the next 3 entries to the SDR USB Serial Number below. If connecting via a remote connection to another mac or raspberry pi please see that section of the rtl_433 documentation as the setup is identical.
SDR USB Serial Number: as of this moment only a single radio can be used with the rtlamr plugin on each machine. There are differences about selecting one with a serial number as opposed to an index that I haven’t quite sorted out yet. If you need this sooner rather than later please drop me a note and I’ll move it up the list of priorities.
rtl_tcp port number: There are 2 parts to an rtlamr connection to the radio making it more complex than the rtl_433 connection. rtlamr does not directly talk to the radio but rather wants to connect to an instance of rtl_tcp (which is already available to it if you’re connecting on your Mac and is installed as part of the default rtl_433 install if you’re connecting to a remote pi) each instance of the rtl_tcp program has to have a unique port number just like every other TCP connection to your machine. If you are only using a single rtlamr instance then you can just use the default assuming it does not conflict with anything else on the Mac or Pi. If you are creating multiple ones you should increment that number or otherwise choose other unique numbers less than 65k so that they can connect propertly.
Frequency: The default frequency for the plugin is 912600155Mhz. For some meters or in some places it may be necessary to change or adjust that to receive the messages that you want to. Please see the rtlamr sites, wiki and other discussions for clues as to how to find the signals if they aren’t in the default range.
Protocols: As of this beta only the SCM protocol is enabled. The rest can be enabled but will not create units in XTension but just log their JSON data to the XTension log. If you need to receive any of those please turn them on and collect some of that log output for me and send it to me so that I can figure out exactly what format is being used for the data.
The r900 and r900bcd cannot be used at the same time. They are basically the same but use a different method for encoding the numerical data.
Advanced: Here you would enter any other parameters you want to pass to the rtlamr subprocess directly. For instance once you figure out which meter ID’s belong to you you would probably want to filter out the neighbors so that they don’t create so many extra units in XTension that are not needed. You could enter that here until I get an interface completed for that as a simpler option. Please see the rtlamer wiki linked to above and the Configuration page for more info on the parameters that can be passed beyond what the plugin does by default.
Any valid packets received will result in 2 units being created in XTension. Upon the first reception you’ll get the master unit for that device which will contain the usage amount being sent in the packet. This number will rise with each reception in XTension as you use more of whatever is being metered.
When you receive a second packet from the meter and the value has changed another unit will be created that will be called the “Delta” unit for that meter. This unit will be updated with the change in the usage from the previous reception until this one. You could of course do this yourself with scripting in XTension however this is offered as an easy shortcut for graphing just the momentary usage from one transmission to another.
When a signal is received for a unit that does not yet exist in XTension it is automatically created with a unique name that tries to guess the meter type and includes the ID from the packet. Once this unit is created you can and should change the name to be more descriptive and make more sense to you.