xap frames from remote device through to pachube for my solar collector
26 February, 2012 - 13:37
Hi,
I'm having trouble collecting xap messages to pachube from remote system.
One part of my system uses a joggler(ubuntu) connected with USB/RS232 to my resol solar collector.
I'm using it partly as an excuse to learn python also and using the create examples and xaplib.pm from http://www.dbzoo.com/livebox/hah_xap_python.
from the broadcast side, I'm managing to sucessfully send out packets from the joggler and with the windows xap viewer I can see the packets as I expect them:
xap-header
{
v=12
hop=1
uid=FF000F00
class=xAPBSC.event
source=shawpad.ujog.solar
target=
}
input.state
{
colTemp=-0.40
tankbotTemp=59.90
tanktopTemp=73.00
pump=0
}
I understand that I should probably select a unique uid, but hoping this should be ok for now.
These are transitted every 60 seconds onto the network, no heartbeats, just repeats of this message.
I've have the attached for my hah pachube config page.
The problem is that none of the temps from my solar packet are getting up to pachube, all the other data is logging sucessfully and feed is live (not frozen).
The pachube log file on hah is empty.
I figure I'm missing something in hah, but after looking around I can't quite see what.
Any pointers appreciated,
Ian.
| Attachment | Size |
|---|---|
| Screen Shot 2012-02-26 at 13.32.38.png | 194.11 KB |
Firstly this message is not compliant to the xAPBSC specification. I would construct your own class and not shoe horn your message into a BSC event message. Many assumptions inside various programs are going to be wrong and the results will be unpredictable. Not to mentioned that won't be able to use this message with the Flash GUI anyway as it MUST be fully BSC if you start down this track.
What about something as simple as this instead? Yes your UID should be unique but not a biggy for now.
I would also stick to using LOWERCASE key names, the xAP specification is case agnostic but if things aren't working its a good thing to tweak (for now).
xap-header
{
v=12
hop=1
uid=FF000F00
class=solar.event
source=shawpad.ujog.solar
}
data
{
coltemp=-0.40
tankbottemp=59.90
tanktoptemp=73.00
pump=0
}
Just make up a new class say 'solar.event' and as there is no target drop the key from the xap-header.
Adjust the pachube keys to suit this new class, there should not be any reason that this won't be processed by pachube. Remember after updating the keys on the web interface you need to restart the xap-pachube process (also via the web interface).
On python I did this VERY early on in the projects life, I too now use a joggler but I ported the LUA interpreter to it and run all the livebox code LUA applets unchanged. LUA on the joggler is a much better environment to work with IMHO than python. What is cool is an Applet on the joggler runs unmodified on the livebox too.
If you do want to circle back and make this a BSC compliant each of these KEYS in the message above would be an BSC endpoint in its own right. This is VERY easy to do using the LUA bsc framework. Its little hard with Python as I discontinued working on this in support of LUA. Python its more thought provoking then a development path.
I've uploaded compiled binaries and the environment I use on my Joggler for running LUA scripts, it also includes xap-hub, xap-pachube, xap-serial, xap-plugboard and iServer - there is no web interface so you need to tweak everything in /etc/xap-livebox.ini to get things started. Its the same syntax as those programs on the livebox. Don't forget each of these will need an a UNIQUE UID key in the xap-livebox.ini file too so they don't collide with your livebox.
Anyway that should get you thinking for a bit.
Brett