ohmhour integration

117 views
Skip to first unread message

Danny ter Haar

unread,
Nov 15, 2015, 11:42:36 PM11/15/15
to OpenEVSE
Ohmhour is a concept of www.ohmconnect.com
They have setup a system when there is dirty electricity, you can get paid if you save electricity compared to your average usage around that time.
I have been using it a while, invested heavy in toys^H^H^H^Helectronics to basically run my house of UPS when such an event occurs.

Thanks to the new RAPI functionality of the huzzah wifi module, I thought it would be nice to see if I could build functionality to totally stop charging of my EV in such an event.

I setup a computer (server) that checks every minute if there is such an event.
if that is the case, it sends a "disable" command ($FD) to the huzzah rapi interface and the display turns pink and shows "Disabled"

when Ohmhour event is over I enable it again with the $FE rapi command.

I just tried it out with my EV connected.
The openevse is at the timer , starting charging in +- 2 hours from now

I send the disable command, unit turns to disable
I send the enable command, unit turns to READY and starts charging.... 


Arggghhhh that is not what I wanted. 
I wanted it to go back to it's sleep mode , waiting for the timer enabled periode.

Is this possible ?



Here the bash script I wrote that is started every minute by CRON to check for ohmhour.

#!/bin/bash
curl https://login.ohmconnect.com/verify-ohm-hour/[HERE_UNIQUE_ID_FROM_OHMCONNECT_SETTINGS] 2>/dev/null | xmllint --xpath '//ohmhour/active/text()' - | grep True > /dev/null
if [ $? == 0 ];
then
echo "$(DATE) ohmhour active" >> /var/log/ohmhour.log
wget http://[IP_ADDRESS_OR_NAME_OF_HUZZAH_ON_LAN]/r\?rapi=\$FD -O /dev/null
 exit 1
else
#no Ohmhour
wget http://[IP_ADDRESS_OR_NAME_OF_HUZZAH_ON_LAN]/r\?rapi=\$FE -O /dev/null
fi

GoldServe

unread,
Nov 16, 2015, 12:24:28 AM11/16/15
to OpenEVSE
Try $FS to sleep the EVSE. It will start charging if you are in the window of the delay timer.

Danny ter Haar

unread,
Nov 16, 2015, 10:37:07 AM11/16/15
to OpenEVSE


On Sunday, November 15, 2015 at 9:24:28 PM UTC-8, GoldServe wrote:
Try $FS to sleep the EVSE. It will start charging if you are in the window of the delay timer.

My script "enables" the unit every minute. I don't want my computer to be either a state machine or keep
track of time to put it either in "enabled" or in "sleep" mode depending on time of day.
That should be the function of the openevse.
It should have a toggle "enable/disable" and go back to the old state before it was flipped.
Currently the "enable" command overrides the timer that is set on the openevese which imho is plain wrong/unwanted.

Is that possible ? 

Craig Kirkpatrick

unread,
Nov 16, 2015, 11:00:15 AM11/16/15
to OpenEVSE
I understand.  I'll take a look at the code later today or early this week to see what can easily be done.

Craig Kirkpatrick

unread,
Nov 16, 2015, 2:04:06 PM11/16/15
to OpenEVSE
Danny, quit using $FD.  I feel really bad for suggesting it.

I was looking at the code and I thought I had a clever idea how to help you and I read the code behind the Disable.  It is a panic stop.  The undesirable side effect is that if you are charging then the contactor or relay will arc.  Arcing contactor or relays is not a good thing and we usually only do this purposely when a GFI event occurs since electrical safety is more important than relay longevity in that case.

$FS to go to sleep is a graceful stop that uses the pilot signal to tell the car to quit drawing current and we open contactor or relays with no current flowing and that is the normal case for all EVSE state transitions.

I need to completely rethink what I was considering for your application.  Thanks for explaining what you are trying to do with Ohmhour.  I need to give a lot of thought to how best to handle what you are trying to do.

Again, sorry I ever lead you to begin using the $FD command.  I should have done my homework first. 
-Craig K.

Danny ter Haar

unread,
Nov 16, 2015, 2:46:57 PM11/16/15
to OpenEVSE


On Monday, November 16, 2015 at 11:04:06 AM UTC-8, Craig Kirkpatrick wrote:
Danny, quit using $FD.  I feel really bad for suggesting it.
Okay, understood.

That still leaves the real problem
I need to completely rethink what I was considering for your application.  Thanks for explaining what you are trying to do with Ohmhour.  I need to give a lot of thought to how best to handle what you are trying to do.

Again, sorry I ever lead you to begin using the $FD command.  I should have done my homework first. 
-Craig K.

When I power cycle the  openevse, the timer detects it is "expensive" time, display goes to purple and sleeps.
My code detects every minute it is not ohmhour and sends "enable" code, which could be the wrong code.
It directly enables the openevse to start charging.

So my renewed question(s) should be

How could I disable an openevse from doing _anything_ during certain times of the day (on command)  "disable mode"
and when I say "go" it should go back to the mode it was before I issued the disable command  "resume mode"

Thanks for thinking along

Danny

Craig Kirkpatrick

unread,
Nov 16, 2015, 3:00:05 PM11/16/15
to OpenEVSE
Yep.  I clearly see what you need.  I need to think about how to accomplish it most economically since there is not a boat-load of firmware space available to work within.  Presently I'm thinking we need another pair of RAPI commands to do exactly what you wish, while leaving the $FS $FE $FD alone.  I won't have more time to study it today, so be patient while I look into it.

Ted Drain

unread,
Nov 16, 2015, 5:56:15 PM11/16/15
to OpenEVSE
Craig,
It might also be a good idea to add some comments to the RAPI doc's about what $FD is really doing and when it might be appropriate to use it.

Ted

lincomatic

unread,
Nov 17, 2015, 5:28:01 PM11/17/15
to open...@googlegroups.com
try sending sleep instead of enable? sorry, I'm out now and can't check the code

Sent from my iCrap
--
You received this message because you are subscribed to the Google Groups "OpenEVSE" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openevse+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Danny ter Haar

unread,
Nov 17, 2015, 9:15:32 PM11/17/15
to OpenEVSE


On Tuesday, November 17, 2015 at 2:28:01 PM UTC-8, lincomatic wrote:
try sending sleep instead of enable? sorry, I'm out now and can't check the code

When i put it in sleep mode and the timer detects "hee we can switch to charging now" it will switch on.

I would really like a "suspend/resume" situation (if at all possible)

lincomatic

unread,
Nov 18, 2015, 9:54:15 AM11/18/15
to open...@googlegroups.com
No, I think if you send it disable $FD to begin ohmhour and sleep $FS to end ohmhour, it will do what you want.

Sent from my iCrap
--

lincomatic

unread,
Nov 18, 2015, 10:09:18 AM11/18/15
to open...@googlegroups.com
To avoid arcing use $FS followed by $FD to disable, and then $FS to go back to sleep when ohmhour is done. 

Another way is disable the timer then sleep when ohmhour starts. When ohmhour is done, send enable timer. It will stay asleep if necessary or wake up if the timer needs it to

Sent from my iCrap

lincomatic

unread,
Nov 19, 2015, 5:50:14 PM11/19/15
to open...@googlegroups.com

I forgot to add… a delay is needed between the $FS and $FD to allow the EVSE to open its contactor… so..

ohmhour start: $FS, wait 1 sec, $FD

ohmhour end: $FS

 

or even better,

ohmhour start: disable timer with  $ST 0 0 0 0*0B, then sleep $FS

ohmhour end: renable timer with $ST.

I guess the missing piece to this, method, however, is that there’s currently no RAPI command to query the current timer setting, which you need to restore the previous one, but it will work OK if you have a fixed timer setting that you always use.

Danny ter Haar

unread,
Nov 19, 2015, 5:57:59 PM11/19/15
to OpenEVSE


On Thursday, November 19, 2015 at 2:50:14 PM UTC-8, lincomatic wrote:

ohmhour start: disable timer with  $ST 0 0 0 0*0B, then sleep $FS

ohmhour end: renable timer with $ST.

I guess the missing piece to this, method, however, is that there’s currently no RAPI command to query the current timer setting, which you need to restore the previous one, but it will work OK if you have a fixed timer setting that you always use.


WHat if ohmhour overlaps the start time of the timer ?

So EV is connected, openevse is waiting for timer.
Ohmhour occurs
start time timer passes
ohmhour ends
we turn it back on to timer.
so that night the EV doesn't get charged.
 

lincomatic

unread,
Nov 20, 2015, 12:01:57 AM11/20/15
to open...@googlegroups.com

If that were the case, then you wouldn’t be having trouble with trying to sleep it while the timer is on.

The timer will start charging any time during the charging window. It doesn’t only trip at the start time.

Danny ter Haar

unread,
Nov 20, 2015, 12:30:55 AM11/20/15
to OpenEVSE


On Thursday, November 19, 2015 at 9:01:57 PM UTC-8, lincomatic wrote:

If that were the case, then you wouldn’t be having trouble with trying to sleep it while the timer is on.

The timer will start charging any time during the charging window. It doesn’t only trip at the start time.



So I will still have to make the computer a state machine.
Currently my script checks every minute.
If I would send a $FS, it would go to sleep every minute while it was charging with the timer on.
So I need to make my program more intelligent that it only sends a command when it detects a state change:

ohmhour -> no ohmhour -> send sleep
no ohmhour -> ohmhour -> send sleep && send disable.

Will try ;-) 

Danny ter Haar

unread,
Nov 20, 2015, 10:20:53 PM11/20/15
to OpenEVSE
Used this script and it seemed to work ;-)

#!/bin/bash 
file="/tmp/ohmhour.active" 
 
curl https://login.ohmconnect.com/verify-ohm-hour/[CODE] 2>/dev/null | xmllint --xpath '//ohmhour/active/text()' - | grep True > /dev/null 

 
if [ $? == 0 ]; 
 then 
   if [ -f "$file" ] 
   then 
     echo "ohmhour already detected" 
   else 
     echo "$(date) ohmhour started" >> /var/log/ohmhour.log 
     wget http://huzzah/r\?rapi=\$FS -O /dev/null
     sleep 1
     wget http://huzzah/r\?rapi=\$FD -O /dev/null 
     wget http://huzzah/r\?rapi=\$FB\ 3 -O /dev/null
     touch $file 
   fi 
 exit 1 
 
else 
  if [ -f "$file" ] 
  then 
    echo "$(date) Ohmhour ended" >> /var/log/ohmhour.log 
    wget http://huzzahr\?rapi=\$FS  2>&1 -O /dev/null 
    rm $file 
    exit 1 
  else 
    echo "no ohmour, nothing to see, move along" 
  fi 
fi 

We just had ohmhour between 6-7pm and my openevse went to "disabled" (technically first sleep, than disabled, but it was already in sleep mode)
I also turned the display red after it went to disable mode 

It went back to sleep mode after ohmhour was over 
Timer will enable in 2 hours from now.

Chris, 
how much programming space is left in the huzzah ?
Is there support for interpreting the rapi commands in the huzzah itself ?

chris1howell .

unread,
Nov 21, 2015, 11:12:23 AM11/21/15
to OpenEVSE

There is a lot of space compared to the 328p on OpenEVSE. The Huzzah has a 4Mb flash chip. 1Mb is reserved for Programs and 3Mb is a file system. I have not even played with the file system yet. I plan to load some images and html files there and see if I can make a more modern UI. The latest versions of the Arduino ESP8266 tool has the libraries and examples for file system operations.

I am not sure what you mean about RAPI commands. Are you asking if we can create new commands that the Huzzah will read and in turn issue a different command or a series of commands?

Danny ter Haar

unread,
Nov 21, 2015, 12:50:23 PM11/21/15
to OpenEVSE


On Saturday, November 21, 2015 at 8:12:23 AM UTC-8, Chris wrote:

I am not sure what you mean about RAPI commands. Are you asking if we can create new commands that the Huzzah will read and in turn issue a different command or a series of commands?


I would like to try and do ohmhour detection in the huzzah.
It would mean that the huzzah  should be able to "interpret" the output of a rapi command.
Is that fairly easy to do ?

chris1howell .

unread,
Nov 21, 2015, 1:05:34 PM11/21/15
to OpenEVSE

The reason ohmhour is not on the huzzah is the ohmconnect servers are using https. The Huzzah does support https but it is not yet part of the Arduino ESP8266 tools.

So either ohmconnect needs to accept the request and send the response http.

Or

We need to wait for https support from the Arduino ESP8266 team.

lincomatic

unread,
Nov 21, 2015, 2:13:09 PM11/21/15
to open...@googlegroups.com
The Espressif SDK can handle https, but it has a steeper learning curve

Sent from my iCrap
--

Danny ter Haar

unread,
Nov 23, 2015, 11:10:25 PM11/23/15
to OpenEVSE


On Friday, November 20, 2015 at 7:20:53 PM UTC-8, Danny ter Haar wrote:
Used this script and it seemed to work ;-)

I am glad to report a couple of ohmhour events have been successfully recorded.

$ tail -f /var/log/ohmhour.log 
Fri Nov 20 18:24:00 PST 2015 ohmhour started
Fri Nov 20 18:24:01 PST 2015 ohmhour started
Fri Nov 20 19:00:01 PST 2015 Ohmhour ended
Sun Nov 22 22:22:01 PST 2015 ohmhour started
Sun Nov 22 23:00:01 PST 2015 Ohmhour ended
Mon Nov 23 19:08:01 PST 2015 ohmhour started
Mon Nov 23 19:14:01 PST 2015 Ohmhour ended
Mon Nov 23 19:15:09 PST 2015 ohmhour started
Mon Nov 23 20:00:01 PST 2015 Ohmhour ended

The sunday session actually stopped my EV from charging.
Next step is the integration on the huzzah itself but as described by Chris/Sam it will take some serious effort to achieve that.

Danny ter Haar

unread,
Nov 26, 2015, 5:49:31 PM11/26/15
to OpenEVSE
Here a graphic of my home's power usage during ohmhour event between 10 & 11pm

http://pvoutput.org/intraday.jsp?id=7071&sid=6390&dt=20151126&gs=0&m=0

Huzzah module nicely switched off the openevse to sleep & disable
Afterwards it was put back to sleep but the timer code enabled it again.

I like how awesome open hard&software is !
Thanks all!

Craig Kirkpatrick

unread,
Nov 27, 2015, 8:15:11 PM11/27/15
to OpenEVSE
That is very nifty!  I'm so happy you were able to get it working with Lincomatic's clever suggestions for the RAPI commands.
Reply all
Reply to author
Forward
0 new messages