@stuart
I get the following error when running the script… ERROR MainThread Unable to create 'SMASolar' interfacer: __i__() got an unexpected keyword argument 'readdcvalues'
Thank You Stuart!
I don’t know how on earth “readdcvalues” got in the config fine.
It all working now
Have you thought any more on pulling data from multiable interters?
Further to the points I raise in that linked thread (send size throttling, max buffer size, log message text/positions and over-logging), the following issues also need to be tackled with the http buffering implementation.
“if int(self._settings[‘senddata’]):” cannot be where it is currently as this switch doesn’t directly control whether the data is sent, it controls whether the data is passed to the interfacer, the data must be consumed, the interfacer cannot just say “no I do not want the data” because that leaves it backing up on the queue using up ram.
The call to bulk post cannot reside inside the loop that adds the data to the buffer, if data is not regular the data in the buffer might never be sent if the network comes up after the last frame is put on the buffer.
The sendinterval switch cannot stay where it is as it allows the interfacer to sit idle between sends and only when the interval has passed will it processes the queue into the buffer before trying to send.
There are a lot of ifs and buts that prevent this code from doing anything at all unless all conditions met and then it does everything as one big packet, it empties the whole queue into the buffer, it then copies the whole buffer into a request and sends it, if it succeeds it deletes all of the “buffered” data directly from the queue, if it fails it will not retry again for 30secs and when it does retry it restarts from the beginning with an empty buffer, reloading every frame from the queue to the buffer, then to the request, this really isn’t the best way to do things.
These are just the “crucial” bits to make it work, there are also a number of things that are just not good practice, advisable or needed, mainly where inheritance and sub-classing has been ignored in favour of rewriting common code in multiple places, The biggest offender here is pretty much the whole action method which is most of the interfacer, most of this code should be in the run method of the basic interfacer and not over-ridden. The rest should be in the send method and most of whats in the send method belongs in the action method so that the data is sent regardless of whether/when any new data gets added to the buffer. The actual sending of the http request and the return of the response belongs in a separate method that belongs to a generic http interfacer class that this interfacer sub-classes, this is so that a (for example) pvoutput interfacer could also sub-class the generic http class and only the action method would be different as that is where the buffer gets parsed into a url and that generic “url_send_method” would get called and the raw reply passed back for that same action method to handle.
Just for the record, the action method is also where an independent and regular call to the emoncms/feed/fetch api could be made and that payload of feed values passed back into emonhub (remember why we made emonhub bidirectional and mulichannel) on a different channel that (for example) the MQTT interfacer is listening to, so that the data is published to the topic of your choice.
BUT, the mqtt development is blocked by the same things as this interfacer, it is too “bespoke” and written with an extremely narrow scope, plus the naming is no good, only a generic MQTT interfacer should be called mqttinterfacer, the bespoke emoncms mqtt interfacer should have been named emoncmsmqttinterfacer and the methods for subscribing and publishing should reside in the generic mqtt interfacer.
Getting processed feeds data from emoncms(org) on to mqtt should be as easy as defining a list of feed ids, an interval, a topic and a couple of other settings eg single mqtt topic or per value