Archived Forum

Hi sheppy

How is the "timed override" managed?

Given the scenario you describe I would be looking at informing emoncms of when the "timed override" is in play by posting a "timed override status" and that could be triggered along with the switchover. eg a cron job to send 2 commands A) switchover powersource B) update emoncms input. Once you have a override status input of 1 or 0 it becomes easier to use a 'x override status' process to log to separate feeds.

The processlist is stored in the inputs mySQL table so it is possible using mySQL but not ideally the way to go. That being said if determined, you could use the emoncms "Input process actions" api's to delete and rebuild the processlist at each changeover but that's messy too.

Paul

Hi Paul,

the changeover is using 2 timers with changeover contacts so they'll  never be an exact time match to EMONCMS and . I'm not a programmer and I don't know anything about SQL in any depth, is it difficult to learn? 

Is there a simpler way for a novice?

Cheers

Kevin

"the changeover is using 2 timers with changeover contacts" So you are looking for an approximation of the changeover(s) based on time, rather than an aligned notification. The best wat forward at this point is still to use cron, (assuming you are using a Pi or linux PC, windows scheduler or the mac equivalent otherwise).

The concept would be the same except you would be just setting the trigger time(s) to match the timer(s). It's easy to do and gives you the flexibility to operate them at different times.

Even if you did go the SQL route or your original text file question these would still need timed triggers so they do not alter the source of the trigger just how the processing is done, and that is easily managed with a "x override status" feed so cron plus override status feed is definitely easier.

You could actually do away with the timers by manually switching the opto-triac switch  (either within the code or on the physical circuit) rather than the diversion logic. This would not only remove the need for the timers, it would align the switching and provide a route to adding a manual "+1hr boost" via a emoncms button or accommodating seasonal/lifestyle changes or even adding a temp sensor etc.

Whether you keep the timers or not cron is the best way to tell emoncms of a timed event. I use this method to switch the unit price of my elec for peak and off-peak to provide a pence per hour rate of use throughout the day.

Paul 

EDIT - An after thought is that I believe the extended emoncms has a scheduler but I'm not familiar with that version, the cron method I can walk you through but need to know if you are running emonhub and/or local emoncms, versions etc. My points about manually switching the diverter rather than the timers was based on the assumption you are using a Mk2 or similar but may apply to others too. 

Check this: http://openenergymonitor.org/emon/node/10019

Available on Extended version.

You can program you inputlist with scheduled conditions to log to different feeds.

Paul,

I am keen for you to walk me through this although I'm using a standalone diverter (SolaControla on the HWC plus a slave unit for the spa.) EMONCMS and the diverter aren't connected unless I add in a relay board to replace the timers. This idea does have merit as it would allow me to switch the water heating back on when I've been away from home, however I would still have to provide a press here to turn on button for my significant other.

I currently use my pi2 as the main EMONHUB > EMONCMS source. I also have a feed to EMONCMS.org but this is historical and can be removed.

I've been in IT for years, however Raspbian is a new thing to me. I prefer using text files where possible as its what I regularly do however I'm happy to go the SQL route if it makes sense

Kevin

Thanks for that, it looks promising however I'm on the low write version due to using a SD Card.

Is there any way to get the scheduler into the low write version of EMONCMS?

Hi Kevin

I wouldn't recommend the SQL route, the point was rather than text file the processlist is held in an SQL table and therefore it is probably possible to edit via SQL.This only manipulates the processlist for which you still need a timed trigger. If the timed trigger is pointed at emoncms directly the processing can be done without manipulating the proceslist at each time period change.

I'm afraid I have no idea about the extended scheduler, It looks fantastic and yes I would expect you could find a away to use it with your existing set-up, but I have no experience, there is no easy-how-to-guide and it might not be straight forward or compatible. The extra learning curve, potential hiccups and additional overhead may not pay off for just a timed input 

You probably cannot interact with that diverter directly (not easily anyway) so best to tackle the load switching as a separate thing after you have the monitoring sorted.

I highly recommend using cron​.

Unlock the read-only filesystem

rpi-rw

​Open a new crontab for emonhub

sudo crontab -u emonhub -e

add the following to the end, replacing MM and HH (24hr clock) for test purposes you can set a trigger to happen in a few minutes time and the other for a minute or 2 after that. You can also use a different node id I have preselected 28 to keep this towards the bottom of your inputs page.

# Timer on period start
MM HH * * * /bin/bash -c 'echo -e "28 1\r" > /dev/tcp/localhost/50011'
# Timer on period end
MM HH * * * /bin/bash -c 'echo -e "28 0\r" > /dev/tcp/localhost/50011'

Save and exit the crontab ctrl-x, Y & enter, open emonhub.conf for editing

emonhub -c

add the following to the [interfacers] section

[[Timers]]
    Type = EmonHubSocketInterfacer
    [[[init_settings]]]
        port_nb = 50011
    [[[runtimesettings]]]

Job done! You should see input 28 appear in emoncms with a value of 1 at the 1st time you set and that value should update to 0 at the second time. To change the times use

rpi-rw
sudo crontab -u emonhub -e

There are many ways of flaying the proverbial moggy but I think this best suits the need, it's the easiest to implement and use so I've included it as an option.

Paul

Thanks Paul,

Unfortunately I failed at the first line - see below

pi@emonbase ~ $ sudo crontab -u emonhub
crontab: usage error: file name must be specified for replace
usage:  crontab [-u user] file
        crontab [ -u user ] [ -i ] { -e | -l | -r }
                (default operation is replace, per 1003.2)
        -e      (edit user's crontab)
        -l      (list user's crontab)
        -r      (delete user's crontab)
        -i      (prompt before deleting user's crontab)
pi@emonbase ~ $

Ahh! there should of been a trailing "-e" on the command (I've updated it now). I was working from memory as I have it added to the emonhub "menu" of commands now and just use "emonhub -t" to edit the emonhub crontab (even in read-only mode).

Paul

That worked once I remembered to set the times in UTC.

I now have an input that updates from 0 to 1 and back again at the times set in Cron

Is there a way of converting this into an input that enables and then disables at certain times?

Thanks for the info, very interesting. Unfortunately I'm on the low write version due to using a Pi and SDCard. Is there a way of manually adding this to the low write version?

Different timezones can be accommodated in cron by switching to the required timezone code before use. For example my off-peak period (00:15 - 07:15) doesn't follow DST so as the RPi timezone is set to the local timezone I define the UTC timezone for those events in cron like this.

# Economy7 tarrif daily time periods do not follow DST so use UTC.
TZ=UTC
15 00 * * * /bin/bash -c 'echo -e "14 0 1\r" > /dev/tcp/localhost/50011'
15 07 * * * /bin/bash -c 'echo -e "14 1 0\r" > /dev/tcp/localhost/50011'

In this sample you can also see I have 2 values (inputs) for node 14 which switch oppositely, this was an easy way to achieve peak on/off & off-peak on/off feeds. since then I have moved to using just one value for a variety of reasons.

In emoncms the input processing for that single input (for your application) could be 

log to feed "Boost period" (phptimeseries variable interval)
x -1
+ 1
log to feed "Diverter mode" (phptimeseries variable interval)

All other calculations should be done in the more frequently updated inputs using x feeds "Boost period" and "Diverter mode"

Paul

Thanks Paul,

I'll have a play over the next couple of days and report back