I’m a total NOOB to OpenEnergyMonitor having just set up a base installation of Emoncms on using the Pi SD image. My main use case is to leverage DemandShaper to allow me to make use of Octopus Agile rates to start/stop an immersion heater (later I will look into OpenEVSE and other use cases). I am using a Sonoff Pow R2 device flashed with Tasmota and have setup Node-RED for MQTT message routing/manipulation. Is there an MQTT or other API I can follow to allow the device to appear in DemandShaper?
I have read about the messages that will be sent from DemandShaper to the device but not the handshaking at device pairing etc…
The demand shaper process publishes the schedule configuration to a MQTT topic that the device subscribes to, e.g:
If you use a base topic of emon/, emoncms will read that topic back in (you will see it on the inputs page). It is better to publish on a different topic to the receipt topic.
I don’t think there is such a thing - it is just the passing of MQTT messages.
However, I’m not familiar with DemandShaper itself.
If this was done on the same Pi, this may cause issues - just so you are aware.
You can use Tasmota rules to do some of the topic manipulation I believe.
You can manage your Tasmota devices through tdmgr.
Thanks, @borpin, that’s all clear. I’ve managed to publish the status from the Tasmota device in to Emoncms but it’s the DemandShaper application that appears to be a mystery to integrate with. The worst case would be for me to pull the code from GitHub and reverse engineer the API used - I was hoping it was clearly documented somewhere as it appears to be a great feature to leverage.
Thanks, I’ve read that post and would be good if I were to flash the device to the bespoke firmware but I was hoping to keep it setup as Tasmota and integrate it with software. It does give me an alternative option if there is no other way.
@borpin, yes, I’ll take that approach. After re-reading that post I just noticed the UDP discovery packet sent out. I’ll check through the code, find the expected response and work progressively through. All being well I’ll have a NR flow that I can share later. Thanks for your advice.
The UDP side of things is optional, it’s just there to simplify the initial setup with EmonESP, the OpenEVSE EV charger integration does not make use of / implement this so you can make it work without it.
How? DemandShaper just sits there waiting for something from the smart plug that never comes.
I think I must be too stupid to understand what of that is necessary and what is optional. I can’t see ip or temperature in the tasmota MQTT to convert its output into the format used, and I don’t understand what the simulator does with ctrlmode and timer messages: it looks like it just parrots them back in the next state message but surely that’s not a useful test?
It’s been a while since I’ve worked on the code for this module as my focus has been elsewhere, I would like to get it working again with the latest EmonEVSE at some point as Im missing the functionality since I upgraded…
