Running pre beta 5, I've noticed the joggler reboot about 3 times over the last 3 or 4 weeks (that's when I've been sitting next to it). Has anyone else seen this? XapFlash is left running on the joggler.
Gary,
I have reworked some timers in beta 6 that I think were contributing to this issue and causing xAPFlash not to be able to reconnect if iServer was restarted whilst it had attached clients . I don't believe there is any issue within iServer.
Whilst this doesn't explain why the disconnects were happening ( I sent you a few thoughts by email ) it should mean that it will reconnect OK.
I'll be in touch by email tomorrow.
K
Running pre beta 5, I've noticed the joggler reboot about 3 times over the last 3 or 4 weeks (that's when I've been sitting next to it). Has anyone else seen this? XapFlash is left running on the joggler.
Hi Digizz, yes both Kevin and I have noticed this but it's very difficult to pin down cause. Funnily as I was saying to Kevin, I have noticed it happening less over the last couple of weeks.
Three thoughts...
Is your Joggler set to use static IP or the default dynamic (DHCP) ? You should use static.
Also ensure that whilst xAPFlash is running the iServer PC is not being turned off / sleeping as xAPFlash depends on that.
Set to false the four <bsc....> tags within your XML too.
(beta 6 will include some fixes for the latter two)
The Joggler seems to change it's dynamic IP frequently (every day after midnight ) and reboots itself when this happens. I think it may also reboot if it fails to contact an internet server when it tries. Many apps are running on the Joggler even whilst xAPFlash is onscreen (every icon is a Flash app).
I have quite a few Jogglers and they used to swap / jump around IP wise all the time - swap IP's and I even suspect there might have been duplicate IP's at one time. For me setting the IP to static has eliminated most (maybe not all) of the reboots. The IP renewal may be an aspect of my DHCP servers lease times but other kit stays where it's told.
If you leave xAPFlash running and come back and instead the home Joggler screen is showing then you know a reboot happened whilst you were away.
K
Thanks guys,
The joggler is using static IP and iServer is permanently running on my HA PC which is running 24/7 without any power saving. I'll look at the BSC tags...
Cheers,
Paul.
A heads up, particularly for those of you running the Livebox HAH from dbzoo.com.
In the latest build, 256, released yesterday, brett has implemented the iServer application within the HAH.
This means that the xAPFlash application, whether in a browser or on a Joggler, no longer need rely on a windows PC to support your flash based interface.
For more info on the Livebox HAH go here
http://www.homeautomationhub.com/
For info on the HAH iServer application go here
http://www.dbzoo.com/livebox/iserver
Obviously this a first release and I know that Brett and Derek would welcome any feedback on any issues you may encounter
Looking forward to trying this out myself!
KevinT
(the other kevin)
Am on it already. My HAH stopped overnight but Brett had already spotted an issue with the new xaplib2 and has implemented a new build since. So I'll wait until tomorrow before I mention it.
The HAH + xAPFlash is now an amazing combo for Home Automation, everything you need for £100 or less! Now all I need is a little time to be able to do some cool configs!
Yes it's a much tidier solution for all the LiveBox HAH 'ers...
Unfortunately I think there's a few issues still to iron out and I seem to have lost touch with Brett just at the moment, it is Thanksgiving over there, so I would hold off until perhaps the next HAH firmware build (258) is released. beta 6 of xAPFlash is also a far better behaved client with iServers.... beta 5 can throw tantrums on reconnects - recommended to restart it instead once iServer is running
Running the HAH iServer (256/257) can create malformed xAP messages on your network, especialy if BSC endpoints are enabled in xAPFlash, and this can cause iServer PC to crash with a runtime error 5 Invalid procedure call or argument . iServer should have been immune to this so it is nice to have found this vulnerability and it's now fixed in v0.12a. HAH iServer 257 could bring down other xAP apps too.
iServer 0.12a.exe download
http://tinyurl.com/37b4ytc
Getting rid of the need for a Windows PC for iServer is a great move. iServer Windows does support additional features and clients still but not needed for this and so for xAPFlash / Jogglers it's ideal
K
PS The xapautomation domain was moved this week to a new hosting service - and on Wednesday we might have missed some mail so if you did email anyone @xapautomation.org on that day they might not have received it. If anyone notices anything not working on the website please let myself and James know.
Last edited by Kevin; 25th November 2010 at 07:07 PM.
Hi kevin
Are you saying that if you run both the original iServer and the HAH iServer at the same time you get these runtime errors on the original iServer? I have turned off the PC iServer for my testing with HAH
I have only been running HAH 257 for a short while and have not experienced any malformed messages yet, but like I said
"Obviously this a first release and I know that Brett and Derek would welcome any feedback on any issues you may encounter"
Since you have mentioned beta 6, can you say what your plans are?
Cheers
kevinT
Yes. HAH iServer is truncating some xAP messages it sends on behalf of clients at an arbitrary place. So in almost all cases of truncation the xAP closing message chr(10) + } is not present. If a xAP app depends on these it will fail. However most apps will probably be able to recover any included parameters successfully. iServer however inspects all xAP parameters in the whole message and so reading the last one fails as it has no end terminator. The b12a update protects against this but in doing so will discard the whole message.
Viewer isn't flagging them but they're there and very frequent - you only really see them if the truncation happens in the header or a key value causing Viewer to flag them. Viewing messages originating from xAPFlash clients reveals themI have only been running HAH 257 for a short while and have not experienced any malformed messages yet
xap-header
{
v=13
hop=1
uid=FF.6996:1029
class=xAPBSC.info
source=UKUSA.xAPFlash.CS4:Button.State.Spots
}
input.state
{
state=?
level=0
My whole HAH is dying after about three hours of running it's inbuilt iServer now too...
I keep posting little snippets in this thread but the main changes are all in the sophistication of the graphics you can now create, they are pretty impressive now even though I say so myself. It's a significant change codewise.Since you have mentioned beta 6, can you say what your plans are?
Beta 6 is actually the beta 5 that was promised but got delayed as feedback was a bit sparse/slow on the pre beta and by the time it arrived there were so many additional changes it was probably no longer really beta 5 or as stable as it was..
So I'm going to put beta 6 out as 'bleeding edge' releases, with quite frequent updates. It will require people migrating their XML a bit and once I know that existing layouts are all working as expected then we'll announce and explore the new features that are included , some are ready and eagerly awaiting testing and some still in progress which we'll document once they're house trained.
K
Last edited by Kevin; 25th November 2010 at 09:23 PM.