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?