xAP Flash nee Joggler beta 5

[BodgeIT]

Sorry Kevin, I put my response togther too quickly.
The button element I use is <mode>control</mode>.
This is what I have for each of the RF buttons I use apart from 2 which are tied to 2 other RF devices by the HAH plugboard. For those I just use <mode>status</mode> and don't expect those to work.
Here's an example:
<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>

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

Already there ;-) was just pointing out which version fixed issue.

I doubt you are needing the new BSC element reporting features within beta 5

The reason I turned them on was I was controlling the screensaver and brightness of the joggler through calendar events kicking off plugboard scripts. During evening SS is on, during day is off but brightness turns down after a bit. Also looking to alter state of on/off button behaviour so that a couple of buttons are always off by default e.g. when you press them they go on moentarily(sending xap message) then plugboard turns them back off.

[Kevin]

OK .. so is there still an on/off issue with xAPBSC.cmd's ?

The reason I turned them on was I was controlling the screensaver and brightness of the joggler through calendar events kicking off plugboard scripts. During evening SS is on, during day is off but brightness turns down after a bit. Also looking to alter state of on/off button behaviour so that a couple of buttons are always off by default e.g. when you press them they go on moentarily(sending xap message) then plugboard turns them back off.

The <bscinternals> will do for the screensaver and brightness - I'll need to check just how far I got with implementing these in terms of external control but as you're using them I guess they're working OK ? Some of the other internals , perhaps volume, may not be complete yet.

...
source=UKUSA.xAPFlash.CS4:Button.Visible.Desk Lamp
}
output.state
{
state=on
}

The button visibility is controllable externally (it presents as an output meaning it can be controlled) but the button state can't be controlled yet as it is presenting as in input.
...
source=UKUSA.xAPFlash.CS4:Button.State.Desk Lamp
}
input.state
{
state=on
level=2/10
}

So you can't currently 'press' a button via xAP. If the button is linked to a xAP device however then you can change that devices state and the button will change it's displayed state.

The level= that is sent inside the state message from a button actually contains the current state out of the 11 currently supported.

TBH There wasn't a real purpose in allowing buttons to be pressed via xAP in beta 5 - but the next beta has a new feature that could make this useful. You are able to add several <xAP><on>/<off> elements within one button so you can create a sequence of commands that control any xAP device - rather like a macro - and being able to trigger this via xAP would be useful.

There are one or two aspects with the BSC messaging in pre beta 5 that can cause large volumes of messages to get sent - this has been honed down a bit in beta 6.

K

[toscal]

Would this work on an Android tablet. As I can get 7" Android tablets for about 85 euros with a slightly more advanced one for 130 euros.

[Kevin]

Android.. theoretically yes but I am not sure how stable or complete the Flash implementation is on Android - and on which version. Needs somebody to try it. There may be some default screen sizing issues until we make the screen size totally arbitrary.

K

[BodgeIT]

Hi Kevin,
I think I was misreading the signs. It looked exactly as it did before the netmask fix and that wasn't working, so I just jumped to the conclusion there was still something wrong.

However, trying to get to the bottom of xAPFlash just loosing sight of device status and sensor info. It mainly seems to happen over night. So most mornings I come in to a screen with no button status and no info from sensors.

I've emailed you recordings of xap messages from xfx. Log file from iServer and screen dump.

By the way is it possible to add xwd to list of vlaid file extensions? Allows for easy upload.

[Kevin]

I leave mine running 24/7 and I'm not seeing this issue - very occasionally I have seen a Joggler reboot, and I do manually reboot when the sound goes crackly.

What does iServer show in terms of connected clients and is it still actively passing information both ways between the xAP network and xAPFlash clients ? Is iServer taking significant CPU time ?

Is this a Joggler screen or a PC screen and do you get the same effect on both if they have both been left running overnight ? Guessing Joggler unless you're running within the emulator.

It would be helpful to put a xAP button on the screen which will show the connected iServer state and any unsynched xAP devices.

So most mornings I come in to a screen with no button status and no info from sensors.

Are you having to relaunch xAP Flash ? It's curious because the displayed data is blank i.e. the temperatures and button states - and yet at xAPFlash launch these would be populated and I don't think having populated them once there is a way that xAP Flash would blank them out (short of HAH reporting blank values) or a relaunch . You don't shut down / restart / hibernate something overnight that is used in the path between the client, iServer and HAH do you e.g. the iServer PC or router ? ... and you are using static IP's for all these things, especially the Joggler , aren't you ?

I'll take a look through the Viewer log file when I get a moment. The log files can be very large so I'd rather they were emailed to me than uploaded to the forum. You can always link to one within a post.

K

[BodgeIT]

very occasionally I have seen a Joggler reboot

I was seeing that too although much less now for some reason.

What does iServer show in terms of connected clients and is it still actively passing information between the xAP network and xAPFlash clients ? Is iServer taking significant CPU time ?

I will provide this info tomorrow.

Is this a Joggler screen or a PC screen and do you get the same effect on both if they have been left running overnight ? Guessing Joggler unless you're running within the emulator.

Will run chrome over night on PC and provide feedback

It would be helpful to put a xAP button on the screen

Done

Are you having to relaunch xAP Flash

No, restart iServer although sometimes I have tried to restart xAPFlash but it doesn't ever get things back, only reset iServer does.

You don't shut down / restart / hibernate something overnight

Good question, but no nothing goes to sleep between Joggler and Server upstairs running iServer

and you are using static IP's for all these things

Yes

[Kevin]

No, restart iServer although sometimes I have tried to restart xAPFlash but it doesn't ever get things back, only reset iServer does.

So - just to be really clear - xAPFlash is correctly showing the status and you leave it running but in the morning the elements have all gone blank and only an iServer restart will recover it ... and the iServer PC is available 24/7 .. not hibernating..

K

[BodgeIT]

Yes. Although it's possible at some point that I did restart xapflash.
I will not this time and check again tomorrow.

[Kevin]

I have looked carefully through the code and I can't find any way that xAPFlash would revert an already displaying state/value back to blank unless it was restarted or HAH sent blank values. As you say the display changes whilst running overnight and as the Viewer log shows HAH is still sending correct values I'm a bit stumped. However I can clearly see that xAPFlash has disconnected from iServer at some time (the log doesnt cover this time period). It would be most useful to have a log that covered the disconnection issue ie overnight Very strange..

<edit> sorry started to post this before your reply above appeared - ahh - then it's possibly just a disconnect and failure to reconnect issue - your logs do show the reconnects are failing, do try and keep a Viewer capture running overnight too although you will have to fix the issue below or it will fill up with those GoogleCal/plugboard messages</edit>

I do note you are using a class B IP address range and so the updated 'broadcast limited' version of iServer will be using a Class C broadcast address x.x.x.255 which might be problematic. I don't know if HAH corrrectly calculates a class B broadcast of x.x.255.255 . As this seems to work for some time based on the capture I dont think it's an issue.

I do notice that you have some GoogleCal action setup in HAH that is repeatedly sending two xapbsc.cmd messages several times per second which seems wrong ???

xap-header
{
v=12
hop=1
uid=FF00DA00
class=xAPBSC.cmd
source=dbzoo.livebox.GoogleCal
target=UKUSA.xAPFlash.ahscs5:ScreenSaver.Hold
}
output.state.1
{
id=*
state=on
}

xap-header
{
v=12
hop=1
uid=FF00DA00
class=xAPBSC.cmd
source=dbzoo.livebox.GoogleCal
target=dbzoo.livebox.Controller:rf.2
}
output.state.1
{
id=*
state=off
}


... also you have plugboard actions again repeatdely sending two xAPbsc.cmd messages again several times each second

xAP-header
{
v=12
hop=1
uid=FF00D800
class=xAPBSC.cmd
source=dbzoo.livebox.Plugboard
target=dbzoo.livebox.Controller:rf.3
}
output.state.1
{
id=*
state=off
}

xAP-header
{
v=12
hop=1
uid=FF00D800
class=xAPBSC.cmd
source=dbzoo.livebox.Plugboard
target=dbzoo.livebox.Controller:rf.3
}
output.state.1
{
id=*
state=off
}

... again this seems wrong - especially as they are identical , these four actions are creating a lot of needless network activity .

Also - in the pre beta 5 build that you have there , within xAPBSC.cmd messages xAPFlash does not support wildcarding of either the target address or the ID= value and so that screensaver hold command will not be working. You should change the ID=* to ID=0003. In beta 6 wildcarding of the ID is supported but it is always faster if you specify the ID= as it doesn't have to search for it.

K