Trace: » Home › Forums › General › News and announcements ›

Release 301

7 replies [Last post]
24 December, 2011 - 17:31
brett
Offline
Providence, United States
Joined: 9 Jan 2010

1 Defect fixed and 2 enhancements.

  • issue 29 Defect - Restore was not working with IE and Chrome browsers
  • issue 28 Enhancement - Support for multiple pachube feeds
  • issue 16 Enhancement- Support for max, min, and units on the pachube feed

Merry Christmas.

Top
1 January, 2012 - 18:58
#1
brett
Offline
Providence, United States
Joined: 9 Jan 2010
Kevin woo hoo

Kevin I thought you might be a little more excited about release 301 where I added support for multiple Pachube feeds as you requested !   See the nice new screen shot -> http://www.dbzoo.com/livebox/pachube

Brett

Top
1 January, 2012 - 20:00
#2
kevin9
Offline
Lincolnshire, United Kingdom
Joined: 24 May 2010
Always impressed

Hey Brett !

Always impressed by yours and Derek's  responsiveness to our requests!  And to get two issues fixed at once as well, thanks very much.

Wishing you both a happy and prosperous new year

kevint

 

 

 

Top
1 January, 2012 - 21:20
#3
andy_godber
Offline
Joined: 13 Sep 2011
Multiple CurrentCosts?

I havent seen Kev's suggestion, but wonder if this release, or future ones, can support multiple Current Cost EnviRs? As you know, they only support 9+1 channels, as does the CC website/dashboard.

I'd really like to be able to have more than 9 IAMs, and the only way to do this is to connect to multiple EnviRs. Looking at the CC XML schema http://www.currentcost.com/cc128/xml.htm, there is a field called <id> which is the "radio id received from the sensor" which I can see does change for each connected IAM. This might be suitable as a 'key' as there is not a unique identifier for the EnviR itself (that I can find).

 

<msg><src>CC128-v1.29</src><dsb>00148</dsb><time>21:19:31</time><tmpr>21.3</tmpr><sensor>2</sensor><id>02539</id><type>1</type><ch1><watts>00529</watts></ch1></msg>

<msg><src>CC128-v1.29</src><dsb>00148</dsb><time>21:19:31</time><tmpr>21.3</tmpr><sensor>4</sensor><id>00699</id><type>1</type><ch1><watts>00000</watts></ch1></msg>

<msg><src>CC128-v1.29</src><dsb>00148</dsb><time>21:19:33</time><tmpr>21.3</tmpr><sensor>1</sensor><id>03577</id><type>1</type><ch1><watts>00378</watts></ch1></msg>

 

Top
1 January, 2012 - 23:33
#4
brett
Offline
Providence, United States
Joined: 9 Jan 2010
Multiple currentcost

I'm not sure I would want to do this as the HAHNodes sort of supercede anything that you can do with an IAM's anyway.

The boards that we use are open source and there are already other compatible boards that we could use for energy monitoring too, you just need to roll some firmware and a backend LUA decoder and you are good to go.  If you check the RF module on this board you will see its the SAME as the one we use so it will play nicely with the HAHCentral sketch ;)

A nice currentcost replacement or IAM replacement!

http://openenergymonitor.org/emon/emontx

Many steps ahead of you - Brett

Top
2 January, 2012 - 09:07
#5
andy_godber
Offline
Joined: 13 Sep 2011
Getting there....

Yes, ive built a couple emonTXs, and documented how Ive used one for water meter monitoring.

Im a big fan, but The slight disadvantages of these devices is they're not 'consumer', i.e clamp and not pass through, needing to be powered externally. Also, CC's devices are more accurate due to true power/voltage monitoring, rather than (albeit quite accurate) calculated values on OEM.

I guess the probem ive discovered with my various projects, is that i end up with my data being deposited in various locations - water in emonCMS, power in Pachube, solar in PVoutput, weather on another website etc. Im hoping HAH could be used as a central monitoring hub to drop everything into Pachube or SQL DB.

Top
2 January, 2012 - 11:58
#6
brett
Offline
Providence, United States
Joined: 9 Jan 2010
one to rule them all

Yup one location to store data is what you need to get to pachube can be destination.  You just need adapters to convert any data being gathered into xAP and you are there.   I love it when people talk about open hardware / open software then lock you into their database.... not sounding very open now is it?

Anyways the emonBase unit is, in a design sense, just a HAHNode, and I know that they use a lot of code from the JCW so I'm betting its not too much effort to remove this from the equation and have the Transmitters feeds straight into the HAH.

The firmware is all published we http://openenergymonitor.org/emon/node/211

So we could hack this and roll our own firmware that would talk to the HAH backend  :)

Note in the readme they say they are compatible with JeeNodes hardware (great) so are we.

https://github.com/openenergymonitor/emonTxFirmware

Brett

Top
3 January, 2012 - 13:49
#7
brett
Offline
Providence, United States
Joined: 9 Jan 2010
eamontx

I was looking at the eamonTx source code its verging on trivial to integrate this as a HAHNode.  By default they use a fixed NODE ID, Frequency and group; 10, 433, 210.  If you adjust this so its in group 212 , Frequency 868 and using the next CLEAR node ID in this group/freq you should pick up its signal on the HAHCentral.

From there you'll be able to write a LUA decoder and integrate these units.   Its so simple.

Brett

Top
Hardware Info