I am looking for some collaborators to implement a DTH/SmartApp to read wireless utility meters.
Most utilities often use “smart meters” to wirelessly read meters these days in US. Smart meters transmit consumption information in the various ISM bands allowing utilities to simply send readers driving through neighborhoods to collect commodity consumption information. One protocol in particular: Encoder Receiver Transmitter by Itron is fairly straight forward to decode and operates in the 900MHz ISM band, well within the tunable range of inexpensive rtl-sdr dongles.
There are some good examples of DTH’s and Smartapps for meter reading, however I haven’t found a supported app/dth for RTL-SDR.
I was planning to adapt the Fortrezz app read water metersd from RTL-SDR via a Raspberry PI - Most of these meters transmit current state data so you typically need another app to collect and record cumulative data. The Raspberry PI would be responsible for reading the meters and collecting cumulative data.
Ideally the DTH should be able to handle multiple meter types and then show appropriate data for each meter type. (Water, Electric, Gas).
However I don’t have a lot of experience with DTHs or SmartApps and if was wonder if anyone can either point out to an example or give guidance on what would be the most efficient way of implementing something like this. Or better yet help code the SmartApp/DTH for this. Please let me know if you are interested and we can figure out how to collaborate on this.
this is an attractive prospect but I have assumed up to now that the smart meters would have some permissions restrictions that would interfere with easy direct integration even for read-only.
It’s worth looking into alright. I would like to be able to refer to another whole-house meter for consumption, plus whatever extra details the smart meter might provide. Certainly not much end-user benefit from the national smart-meter boondoggle up to now.
This seems pretty cool! I just wish my gas meter used wireless AMR tech…
A while back I created an system to listen to 345MHz security sensors in my house with an SDR and push the data into the SmartThings ecosystem. This sounds pretty close to your goal. Have a look at the topic here describing my work. Here is the github repo with all of the code.
Thank you @jh0 that was quite helpful actually - your App/DH are very clean and small enough to easily understand the architecture. Would appreciate if you can help out with a couple of ST concepts - I can probably read it in the docs, but may be a little faster. Here is the stack I am thinking off:
Data collection and recording -
rtl-sdr to talk to device on Pi
2.One or more applications/scripts on Pi talking to rtl-sdr that extract and parse meter data
2a. rtlamr which reads the ltron meters running on Pi and talkting to rtl-sdr – rtlamr has done the heavy lifting of talking to ISM meters, is well maintained so don’t want to get in that buisness
2b. For future other metering reading apps for extensibility, there are solutions people have done which watch the meter needles move and use ESP8266 to monitor data etc, or other wireless stores
Another script(s) on Pi that pushes the meter data to the cloud or Influx databse on Pi - from my reading Influx is being used a lot for time-series iot data
if we use Pi for 3 then will need a Rest request handler for ST on Pi that can return current data point as well as cumulative data
For 3&4 I am a little divided with to do it on the PI or an existing cloud service - that will save a bunch of work but additional dependency also noticing that most backends are even beginning to charge hobbyists now
I am a little less clear technically on how to lay it out on the ST side of things -
I know from a usability perspective, what we need is
User to go to a smartapp - and choose the backend IP etc - and possibly enter credentials for the backend, may need to make it easier if using cloud to authenticated and get tokens from a 3rd party
Add one or more ST things which would be meters
Associate each thing with a type, electric, gas, water and bind it with some tag/identifier for retriving the time series or aggregate data from the backend
Develop rendering software for each Thing that is seen when you go select that Thing from the ST App, I think this would be part of the DH - now here I don’t know if can use one rendering for all kinds of data or need multiple. Given that electricity is priced in tiers I would like to have design in place so in future we can have a more sophisticated DH for electric meters. Initially only one would suffice and depending on meter type we can set the units. BTU, kwh, Gallons/liters or a custom label that way this can be used for any time series thing
So would appreciate if you can suggest, how you would structure the ST things, what do you thing belongs in the App vs DH? I noticed in your code there are some parent/child concepts – how would you apply that here?
Have a look at the background info here in the ST docs regarding the suggested design for this type of integration. My code follows the model described here. The core idea is that you need a parent Smart App (the “Service Manager”) which interacts with the network, and then one or more child Device Handlers which the Service Manager creates and injects with the data from the network.
I’d recommend starting without any sort of cloud connected data management solution or database on the RPi. My that interacts with the SDR just writes a file and sends it to the ST hub using curl.
In my case I need to be able do math on the data - meters are only sending a single digit snapshot, can I do aggregation in a smartapp and store cumulative data there? this week, last week this month that sort of thing