It’s difficult to say whether it is “simpler” and there are other differences that may make one method more suitable than the other. Whilst I have used the schedule module in emoncms for some tasks I still use the cron method for this particular job because
- It was already set up prior to the schedule module being written and has worked well.
- emoncms.org does not have the schedule module (yet???)
- I use multiple emoncms’s and this method serves all with the same data
- The timezone can be set independently of emoncms, this means I can still use my local UK “DST” timezone in emoncms despite my meters tariff times being UTC. This won’t be important if your tariffs are on the same timezone as your emoncms user account and follow DST, you can probably get around this in the schedule module by setting up a more complex schedule with different times set for DST summer and DST winter periods…
- There are some other benefits like easily adding time based service charges if calculating monetary totals
- You can also schedule a change of rate like a price increase and have it applied automatically
The schedule module has the great advantage of being web based so you do not need to ssh in via a console, which means you can edit the schedule from outside your LAN without opening a port (or making another arrangement eg dataplicity). Since meter based time periods are unlikely to change the appeal of that maybe limited and also for that exact same reason I prefer to keep my “permanent tariff periods” in cron were I am unlikely to edit them whilst playing with other schedules.
Here is an example cron entry
# Since my Economy7 tariff daily time periods do not follow DST use UTC.
TZ=UTC
15 0 * * * /bin/bash -c 'echo -e "14 6.949 0 1\r" > /dev/tcp/localhost/50011'
15 7 * * * /bin/bash -c 'echo -e "14 15.807 1 0\r" > /dev/tcp/localhost/50011'
In this example the timezone is defined as UTC so that I can still use a local timezone and the tariff periods still track UTC, I have watched the display on my meter and have confirmed “off-peak” starts at 00:15 and ends at 07:15, so they are the time settings at the start of each of the 2 events (mm hh * * *).
At each event a single packet is sent to a socket opened by emonhub by adding the following to the interfacers section of emonhub.conf
[[cron]]
Type = EmonHubSocketInterfacer
[[[init_settings]]]
port_nb = 50011 # sets the port to listen on, cron must point to this port.
[[[runtimesettings]]]
pubchannels = ToEmonCMS, # only required in the emonpi variant of emonhub
The packet is in the form nodeId unitPrice peakStatus offpeakStatus, ie at 00:15 a packet is sent as node 14 setting the unit price to 6.949p and setting peak status to 0 and off-peak status to 1.
Those last 2 “status” values are the filters for the peak and off peak feeds, by multiplying each incoming increase in kWh by each “status” before adding to the feeds only one will get thorough, the other is zeroed.
The packet can be in many different forms, this is just an example to show how to set it up rather than, specifically what to set up.
The schedule module isn’t officially documented (AFAICT) but there is a guide on the old forum in the EmonCMS multi rate scheduler discussion and further info on this topic can be found on the EmonCMS multi rate energy billing support and emoncms time-of-day filter process threads too.
Another consideration I had hoped top test for but haven’t had the time, is whether the schedule modules events are applied using the current time or the timestamp of the input data. When timestamped data arrives late due to a network outage for example we want to be sure the energy used is logged to the tariff applicable at that time not the tariff that is current if it has changed since. The cron method ensures the tariff period is applied correctly, even if data is buffered for hours or days. I would hope the same can be said for the schedule module but I do not know for sure, this is less likely to be a concern if all is on one machine or if using the emonPi variant of emonhub as data is no longer buffered beyond 30sec (by default).
