Emonbase firmware that allows pulling

Hi forum.

I have been looking around at some other platforms and many seem to favour pulling data from devices, over getting data pushed into the platform(example EmonCMS).
Does Emonbase/EmonPI have such functionality available (that allows pulling of data)? Or is there any such firmware as a alternative? Anyone done something similar with this in regards to the emonbase/emonpi?

cheers

Sorry, I don’t quite understand. Please could you give an example of what you mean.

Mmm how to say…

In the current system, the emonbase SENDS (pushing) data to the Emoncms via a HTTP interface right? example : www.emoncms/input/api/etc.

The system that I am asking about would work other direction:

Example : EmonCMS (or any other platform) REQUESTS (pulling) data from EmonBase. So the EmonBase would have a API endpoint exposed on the internet, and the EmonCMS (or any other platform) would make a intermittent requests that that endpoint.
When the EmonBase gets the requests, it would send back data to the EmonCMS (or any other platform).

My question is whether this type of implementation exists with the EmonBase or if anyone has looked into it?
Does the MQTT protocol allow for something like this? Or is that only relevant to for commutation to EmonPI devices?

I think the answer is history. The emonTx was designed, and can still be used, as a battery-powered device. In that mode, it is much cheaper from the energy requirements viewpoint to transmit a burst of data once every 10 s say, than to sit waiting with a radio receiver continually powered listening for a command to do a measurement and send the data. Memory in the original base, the NanodeRF, was very limited so it wouldn’t be possible to store very much data at all. The base was essentially passive, forwarding the data to emonCMS as it was received from the emonTx.

That’s no longer the case with the RPi as a base. Are you suggesting that the base should store the data and only send on command? Isn’t that what the emonHub/emonBase combination is already capable of in a limited way? In my understanding, if it can’t send the data, it is stored locally until it can. That’s only a small step removed from what you appear to be asking for.

What do you do about the first hop in the data path? If you search the old forums, I think you’ll find proposals that suggested the emonTx could sleep for (say) 9.5 s, then turn on the radio to listen as it expected to be called within the next second, but even so, that is still energy-hungry. Of course, if everything is mains-powered, that problem no longer exists, and polling the devices in turn is most likely the best solution where there are many outstations connecting to one base, because the problem of contention for the radio channel has also gone away.

This would require users to open a hole in their firewall to expose the emonBase to the internet. This would be a difficult and often unfeasible action for many users and pose a high-security risk.

If a user wanted, the emonBase / emonPi’s MQTT server on port 1883 could be exposed to the internet to allow external services to subscribe to topics. MQTT is a publish - subscription type service so really a push

Thanks for the feedback.

There are pro’s and con’s to both approaches. Allowing the EmonHub to be exposed could have benefits such as remote debugging and updating, which might be useful in some cases.
But as you said, it adds a extra layer of complexity and security issues. Something like a VPN might solve this I think?

Ill do some more research on this. It might be that this approach is not suited for power sensitive embedded devices, but rather things like servers and other types of devices / services.