xAP Flash nee Joggler beta 5

[SiliconPixel]

I thought that might be the case - I'll have a look into text boxes although that's a bit fiddly during design - otherwise I'll have to rethink my design.

Cheers,

Paul.

[BodgeIT]

Hi Kevin,
Thought the new update to HAH would bring more clarity, should have known better.
After upgrading I had to reenter new uids for each of my rf devices in my xapconfig.xml. Most other things now work but all the buttons controlling the rf devices don't. When I look at XFX, I see that when I press a button I get an on and immediate off. If it's on it works viceversa. I imagine I will need to bring it up with the guys at HAH but wondered if you had seen this?

Here's my config for the page and a couple of buttons:
<page NAME="Control">
<width>355</width>
<height>266</height>
<visible>true</visible>
<group>Center</group>
<background>
<image></image>
<visible>true</visible>
<posX>165</posX>
<posY>20</posY>
<width>407</width>
<height>220</height>
<border>true</border>
<bordercolour>0x000000</bordercolour>
</background>
<button NAME="TV etc">
<gridX>2</gridX>
<gridY>0</gridY>
<posX>-53</posX>
<posY>+30</posY>
<style>blue</style>
<visible>true</visible>
<xAP>
<schema>xAPBSC</schema>
<uid>FF00DBA0</uid>
<source>dbzoo.livebox.Controller:rf.1</source>
</xAP>
<mode>control</mode>
</button>
<button NAME="Sub Woofer">
<gridX>2</gridX>
<gridY>1</gridY>
<posY>+25</posY>
<posX>-53</posX>
<visible>true</visible>
<style>blue</style>
<xAP>
<schema>xAPBSC</schema>
<uid>FF00DBA3</uid>
<source>dbzoo.livebox.Controller:rf.4</source>
</xAP>
<mode>status</mode>
</button>

Digging some more, I'm getting the same thing on pagetoggle buttons too but these still seem to have the effect of of working.

Any suggestions?

[Kevin]

Hi Kevin,
Thought the new update to HAH would bring more clarity, should have known better.

I updated to firmware 253 yesterday but haven't played much - both Brett and Derek have Jogglers but I dont think either of them are using xAP Flash (yet) - they do intend to try the next beta..

After upgrading I had to reenter new uids for each of my rf devices in my xapconfig.xml.

That's a shame, the UID's are the way that iServer/xAPFlash recognises your xAP devices - if their firmware update changed the UID's that's not very helpful. UID's should persist across restarts and updates. Hopefully they wont change again and it was only a small edit.

HAH has used xAP v1.2 which has a limit of 254 endpoints - and instead of using all 254 they have reused the same low numbers 1,2,3 etc :-( This then means that they have had to change the main UID digits for every application , Pachube, CurrentCost, 1-wire, RF etc which has the effect that their single HAH controller now looks like lots of independent xAP HAH devices on the network... Not ideal but it is workable. Using xAP v1.3 would have been tidier.

Most other things now work but all the buttons controlling the rf devices don't. When I look at XFX, I see that when I press a button I get an on and immediate off. If it's on it works viceversa. I imagine I will need to bring it up with the guys at HAH but wondered if you had seen this?

You mean that xAPFlash is sending an ON command immediately followed by an OFF command or that is the 'event' response coming back from HAH ? If it's the former then it's my issue...

If it's the latter then it's kinda a problem with RF control that has no feedback . I think the HAH guys quite rightly say that they have no means of determining the state of a remote RF controlled device. What they seem to be doing is reporting the state of the transmitted RF signal - i.e. it pulses on and then off. Do they maintain a state in the web UI for RF devices ? If so then I guess they should also xAP report it. xAP Flash will just display whatever state the device that you are controlling is reporting.

I don't use RF control from HAH - In my setup I've tried wherever possible to use devices that can report their status, which in general RF can't , except ZigBee / Z-Wave etc. Where I do have RF control (HomeEasy) I have only controller (RFXCom) and I track it's commands to determine state. It can also report any control messages it hears which could be used to supplement status...

Digging some more, I'm getting the same thing on pagetoggle buttons too but these still seem to have the effect of of working.
Any suggestions?

Ahh ... I think you're now saying that it's the xapbsc.cmd's that are wrong then ??? - but how are you managing to send xAPBSC.cmds from a page toggle button ? Are you adding <xAP><on> and <xAP><off> tags in the XML ? If you have enabled BSC reporting from xAPFlash then remember that the state= represents the visibility of the button and not the state of the device that button is controlling. It does report the buttons displayed state too (which matches the devices state) in the level= parameter using a value of 0-10 corresponding to the 10 possible states a xAP device can be in (on/off/absent/error/blank/highlighted/dimmed etc..)

K

<UPDATE> I have just been trying this with your XML and it does seem that the HAH with firmware version 253 is behaving differently to 252. Does 253 include the new xAP libraries that Brett was writing ? Curiously when the xapbsc.cmd state=toggle message is resent from xFX Viewer to HAH it works every time so Viewer is changing the message - likely by stripping or adding a leading / trailing chr(10) - I'll take a look at the differences in the two messages and update this shortly. I don't see the immediate on/off transition though.

After upgrading I had to reenter new uids for each of my rf devices in my xapconfig.xml. Most other things now work but all the buttons controlling the rf devices don't.

So other things are working - like the relays for example ? For me nothing that is controllable is working. The messages are byte for byte identical so I can only assume now that it's a broadcast address issue maybe...

[Alanmh]

Hi Kevin

I have HAH and am keen to help with testing etc, but not on your beta yet. I did PM you yesterday,.

Apologies for hassling, but am keen to get stuck in

ALan

[Kevin]

I have HAH and am keen to help with testing etc, but not on your beta yet. I did PM you yesterday,.

Apologies for hassling, but am keen to get stuck in

Hi Alan - I did reply this morning .....

beta 5 has not been released as yet and as soon as it is I've got a whole bunch of people wanting to jump in - the more the merrier. You can try the current beta if you wish but quite a bit will need redoing when you move to the formal beta 5..and if your using firmware 253 on HAH looks like there's an issue currently ... up to you..

Brett and I are on the HAH case....

K

[Alanmh]

Strange - just checked my PM nothing there??

ANyway if you and Brett are on it then I cant add much. I would like to get at look at the documentation though to get me up the curve

[Kevin]

I dont know why that PM didnt reach you

Anyway the old documentation link is a few versions back so here are some current (preBeta5) links - an overall xAPFlash dcument and the beta 5 changes. The next beta release will have a few more XML changes I'm afraid...but I dont have that documented yet..

xAP Flash Documentation (v5)

beta5 notes

K

[Kevin]

Brett and I are on the HAH case....

Well we know what the issue is and we're both going to post a fix... either will work but I recommend both.

I understand that Brett has just pushed out firmware 254 :-)

Here's a new build of iServer that will also sort it out. Just replace the existing .exe. Although it should work without I recommend stopping any xAPFlash clients first and then restarting them.

iServer beta 12

K

b12 changes: xAP message traversal restricted to local subnet x.x.x.255 , it was previously 255.255.255.255

[BodgeIT]

Hi Kevin, I had replied but the message seems to have been lost.
Firstly thanks for updating iServer. That's fixed the non working button issue(actually HAH 254 did the trick).
I am still seeing my other issue which is an on/off for every single button press.
It's weird becuase things are now working as the should...ish. I still get iserver getting it's knickers in a twist but mostly controls work.

Are you adding <xAP><on> and <xAP><off> tags in the XML ?

No, just using <mode>pagetoggle</mode>

e.g.
Pressing Radio button whicle it is "On"(i.e. button indictaes on and device is actually on), I get:
xap-header
{
v=13
hop=1
uid=FF.0738:1009
class=xAPBSC.event
source=UKUSA.xAPFlash.ahscs5:Button.State.Radio
}
input.state
{
state=on
text=hello
displaytext=press
}

Followed by:
xap-header
{
v=13
hop=1
uid=FF.0738:1009
class=xAPBSC.event
source=UKUSA.xAPFlash.ahscs5:Button.State.Radio
}
input.state
{
state=off
text=hello
displaytext=press
}

The above single press/double message turned the device off. When pressing again, I get another 2 messages and the device came on.

When I saw the uid updates from HAH253 update, I deleted the known devices list in iserver just to reset, I also rebooted the joggler.

I'm a bit flumoxed.

[Kevin]

Firstly thanks for updating iServer. That's fixed the non working button issue(actually HAH 254 did the trick).

Please do update HAH to 255 firmware as there is a long message bug in 254

I am still seeing my other issue which is an on/off for every single button press.
It's weird because things are now working as the should...ish. I still get iserver getting it's knickers in a twist but mostly controls work.
....using <mode>pagetoggle</mode>

Gary - your're confusing two things here. A <mode>pagetoggle</mode> button is used to toggle the visibility of a page within xAPFlash - it is not used to control any xAP device and it doesn't send any control commands out on xAP at all. If you wish to on/off control a xAP device use <mode>control</mode> or <mode>lcontrol</mode>.

Actually pagetoggle is now deprecated and you should instead use
<mode>link</mode>
<link>pagename</link> where pagename is the name of the page

From beta 5 xAP Flash can also report the visibility of various internal elements - you can enable this separately for various elements (buttons pages textboxes internals) using the BSC tags... my recommendation if you have no use for this feature is to set them all false to avoid unnecessary xAP traffic and any confusion.

<bscinternals>false</bscinternals>
<bscbuttons>false</bscbuttons>
<bsctextboxes>false</bsctextboxes>
<bscpages>false</bscpages>

From beta 6 you'll be able to set them individually for each element too , so you can just enable a particular page or button that you wish to report the visibility of. Note that the button visibility is independent of the page visibility. If a button is visible but on a page that is invisible the button will still report as visible.

For buttons there are two messages - the visibility and the state (pressed/released) reported as Button.State.buttonName and Button.Visibile.buttonName. If a button is set up to control a xAP device eg <mode>control</mode> then it will also send a xapbsc.cmd message.

xap-header
{
v=13
hop=1
uid=FF.0738:1009
class=xAPBSC.event
source=UKUSA.xAPFlash.ahscs5:Button.State.Radio
}
input.state
{
state=on
text=hello
displaytext=press
}

If you look at the two messages you posted the class is xapbsc.event (and not xapbsc.cmd) and so this is an event indicating something has changed - the source line tells you what changed and in this case you will see that the message is coming from xAPFlash and "Button.State.Radio i.e. reporting a press event of the Radio button. As you press it it will show state=on and as soon as you release it then it will send state=off. Ignore the text hello bit and displaytext will show 'press'.

When xAP wants to control something using BSC it has to send a command to that device class=xapbsc.cmd and it also has to include a target= line in the header stating which device it is trying to control . There is no target line in a xapbsc.event or xapbsc.info message. <mode>control</mode> and <mode>lcontrol</mode> buttons send xAPBSC.cmd messages - as do the slider and dimmer controls.

I'm a bit flumoxed.

I doubt you are needing the new BSC element reporting features within beta 5 and so you'll find it clearer if you turn them off using the 4 BSC tags at the top of this post.

Re the iServer 'knickers in a twist' comment - if you can provide more detail or reproducable circumstances it would be helpful. I am aware that xAPFlash clients can somewhat flood iServer with connect requests if iServer is restarted with active connections - in this case the 'xAP' button normally shows a number that counts upwards. It's always best to start iServer before you start the clients and then leave iServer running.

K