The upcoming ST API access fee change is forcing me to look for a new solution to an existing feature, and I wanted to ask if one approach I was thinking of is possible.
I’d like a virtual edge driver that reads values from a couple of devices in my network to obtain current values, sums those values and writes the results to its own capability (to be read by ST system). (Apologies if my terminology is loose as I’ve not touched this stuff for ages.) Ideally this could all run locally on my hub, but that is not important so long as the API subject to fees is avoided.
Longer explanation: My current working use case is I have two physical energy meters (Zwave) measuring different panels, and want the total energy (and power values) evaluated and ultimately exposed via a separate virtual power meter (with some help with the addition and virtual meter update by way of SharpTools). I then use ConstantGraph to log the total power value from the virtual device and log/track it there. (The CG API use “problem” is for now a separate matter.)
I’m not a developer/coder, but can hack existing code that does most of what I want to piece something together, following examples if available. First I’m trying to assess feasibility.
Or if someone has a better idea for a workaround I’d love to hear it!
Although there remains some uncertainty over the details of the API monetisation, I’m am not seeing where it would come in to play in your case. I have not used CG so I have assumed that, like SharpTools, it is a third-party service that would be liable for the API usage charges.
What are you doing using the API that you feel you need to stop doing to avoid being charged a fee yourself?
My explanation was somewhat brief… The known API fee concern (there maybe others I run find later) comes from my SharpTool’s rule I use to perform the sum/update, which gets triggered by changes to the physical meter’s values. The SharpTool folks have been good enough to provide stats showing possible “problem” rules, and mine fits that category - presumably due to the frequency of the particular API calls. I might be able to “fix” it by changing how the rule triggers to be less frequent/periodic, but it becomes less accurate. I was thinking if I need to change something perhaps there’s a “native” solution within the ST environment I can come up with. (I may still face API fee issues with my CG account, but thought to tackle one problem at a time.)
Until recently I probably would have used a Webhook SmartApp for this sort of thing as I already have the luxury of external hosting and so there wouldn’t be any additional cost. SmartApps were relatively well documented for use in automations, though they seemed to be supported without any enthusiasm and the SmartApp Connector variant used for C2C devices was not documented and new integrations vanished from the Developer Workspace a long time ago.
Now SmartApps have vanished from the developer documentation and it isn’t clear what their future is with the Developer Workspace being run down. The recommendation for automations now seems to be API Access apps which are a bit of a sledgehammer for personal use and of course the trigger for personal API subscriptions.
It is very frustrating to see a bloated mobile app full of free tools and services that I consider either unnecessary or not particularly useful, while it becomes increasingly harder and most costly to create our own simple bespoke solutions.
My other solution would be to go down the path @Paul_Oliver suggested, though I would use a bespoke driver for native virtual devices because I try to avoid third-party drivers.
Thanks!