Google Calendar Alias
I don't think the the Google Alias is working correctly. It doesn't produce the xAP message as described on the Wiki, http://www.dbzoo.com/livebox/hah#calendar_aliases.
The debug log below shows the xap-googlecal detecting events, but instead of sending a properly formatted xAP message, it just sends "xap".
Looking at the googlecal.c code, does it have anything to do with a /etc/xap-alias.xml file, which doesn't exist on my HAH.
# xap-googlecal -d 7
Google Calendar Connector for xAP v12
Copyright (C) DBzoo 2009
br0: address 192.168.1.5
br0: netmask 255.255.255.0
Autoconfig: xAP broadcasts on 192.168.1.255:3639
xAP uid=FF00DA00, source=dbzoo.livebox.GoogleCal
Debug level 7
Broadcast socket port 3639 in use
Assuming a hub is active
Socket port 3639 in use
Socket port 3640 in use
Socket port 3641 in use
Socket port 3642 in use
Discovered port 3643
Connecting to google
19:43:00 - Reloading EVENT cache
Google query params: start-min=2010-09-30T19:43:00Z&start-max=2010-09-30T19:44:00Z&singleevents=true
Dump event cache - found 1 events
event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
19:43:00 - Check Trigger events
Trigger event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
Send XAP message
xap
19:44:00 - Reloading EVENT cache
Google query params: start-min=2010-09-30T19:44:00Z&start-max=2010-09-30T19:45:00Z&singleevents=true
Dump event cache - found 2 events
event(title=rf 1 on,start=2010-09-30T20:44:00.000+01:00,end=2010-09-30T20:45:00.000+01:00,where=xap,content=)
event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
19:44:00 - Check Trigger events
Trigger event(title=rf 1 on,start=2010-09-30T20:44:00.000+01:00,end=2010-09-30T20:45:00.000+01:00,where=xap,content=)
Send XAP message
xap
Trigger event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
Send XAP message
xap
19:45:00 - Reloading EVENT cache
Google query params: start-min=2010-09-30T19:45:00Z&start-max=2010-09-30T19:46:00Z&singleevents=true
Dump event cache - found 1 events
event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
19:45:00 - Check Trigger events
Trigger event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
Send XAP message
xap
19:46:00 - Reloading EVENT cache
Google query params: start-min=2010-09-30T19:46:00Z&start-max=2010-09-30T19:47:00Z&singleevents=true
Dump event cache - found 1 events
event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
19:46:00 - Check Trigger events
Trigger event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
Send XAP message
xap
#
I'm going to have a look at this code and see what's going on. It should work as you have stated. You just enter a simple "message" in the what line and a complete welformed xAP class=alias message should be spat out for the plugboard to then interpret.
I might use this opportunity to rewrite it in xaplib2 whilst I'm at it.
Brett
I'm not just trying to be a pain the backside by pointing out stuff that I can't get to work! ;-)
Fortunately most of it is user error!
I've just finished adding some polish to the currentcost daemon. I've added support for external sensors, this is way cool. http://www.dbzoo.com/livebox/xap_currentcost
I'm almost done on that so I'll now tackle google calendar.
Thanks guys for being my guinea pigs testers.
sounds like it's gonna be a big update...how/where do the external sensors work.
Is this just for the cc128?
I know Derek's been busy too...can't wait for the new release.
As Brett said ... these are cool. These 'dev' boards are small Tx units (4cm x 3cm). You pair them to your CurrentCost receiver, just like the 'main' Tx unit that has the clamp ammeter. They need 3V DC power (i used a couple of AA cells). There are two solder pads at the end of the PCB - if you put a switch across these, the unit will transmit the state of the switch every 3 secs. A tiny, surface mount, LED flashes with each transmission.
With the new setup screens that Brett has rolled, you can then specify on the HAH what displaytext you would like on the resulting xAP message that the xap-currentcost will produce. Then a lttle plugboard scripting and it's job done.
Great for open/shut door, window sensing - and at £5 a module (on eBay), not overly expensive.
You can also do analogue readings by placing a resistance across the same two pads.
Only downside is that if the switch operation is of short duration, you might 'miss' the event - the transmitter doesn't latch a switch closure.
AFAIK, the CC Classic unit only has a single channel, so not much use with these dev boards.
I'm still on the case of a BBSB Rx. My proto Rx unit now runs without any 'false positive' receptions. This solution won't have as good a range as the CC dev boards (the CC uses a superior type of RF Tx/Rx module), but won't suffer from the CC 'missed' event issue.
Hi Derek, this all sounds bl**dy brilliant.
I think the CC has 3 channels, at least that's what shows up in my xAP Viewer.
Might have room for 2 of these modules then eh?
Well, it does seem pretty robust. I tried to 'scope out the signal from the dev xmitter, but it's not like the BBSB Tx units where you can scope directly where the micro drives the 'data in' line onto the Tx module. The module is intellignt and uses an SPI bus protocol to talk to and from the micro. Relying on capturing the correct pulsetrain at the Rx end is harder - esp. since there is so much 433MHz activity around here. One train that I did grab looked hugly long.
As for the number of channels. On the CC128 unit, you pick a channel number on the receiver 1..9 (0 is reserved for the clamp ammeter), then 'pair' that channel to the dev board (the dev board has a PCB mounted push switch).
On the Classic, I was able to pair a single dev board to the receiver and it worked well ... not sure how > 1 might be paired.
You would need to send this and then pick up the google calendar produced ALIAS and process. There is already a pre-written script as part of the xap-plugboard demo code that can do this. The only CATCH is that "where=xap" is not supported! I'll add to the work I'm doing on google calendar.
xap-header
{
v=12
hop=1
uid=FF00D800
class=google.calendar
source=dbzoo.livebox.Plugboard
target=dbzoo.livebox.GoogleCal
}
event
{
title=relay 1 on
where=xap
start=19:18
}
/etc/xap-alias.xml is deprecated, this existed before the xap-plugboard was available and the code is still lurking about. If you look at the Makefile you'll see that its not compiled in. I'll remove this code when I rework it with xaplib2.
I suspect the code is working correctly. Did you leave the DESCRIPTION field in your google calendar setting EMPTY as in NOT even some SPACES or BLANK lines ?
If you don't it won't work correctly as a SHORT ALIAS and you'll get what you've just described.
Hmm looking at the trace before this is looks like you have as content is ''
Trigger event(title=rf 1 off,start=2010-09-30T20:25:00.000+01:00,end=2010-09-30T21:26:00.000+01:00,where=xap,content=)
Something fishy is going on !?
Brett