Update to xPLRFX

[martynw]

The Visonic keyfob issue listed above turned out to be (l)user error - I'd forgotten to enable Visonic protocol on the new Visonic receiver.

This meant that xPLRFX was still only seeing Visonic data from the old Visonic receiver (early firmware version).

Once I'd enabled the Visonic protocol on the new Visonic receiver all the keyfobs were picked up correctly.

Martyn

[martynw]

Hi Mal,

I've been running xPLRFX for the past week or so with JUST my LAN interface connected and am still seeing the memory leak issue (was up to 1.5GB today).

Is there anything that I can do further to help diagnose this?

Additionally, I've been away for a few days and came back today to find that late on Sunday night the 434 Transmitter had "stopped" - there was an event in the event log saying this.

However, there were no further events, even though I know that there would have been xPL messages sent since then to transmit stuff. So it appears that xPLRFX does not attempt to recover the Transmitter? Otherwise would I not see additional events in the event log where it had tried to transmit again and failed?

If / when this occurs again I will make sure that I shut down xPLRFX and immediately fire up Berts RFTransmitter program to check if the Transmitter is still alive.....but I assume that it must be since restarting xPLRFX seems to get things going again....

Martyn

[Mal]

Hi Mal,

I've been running xPLRFX for the past week or so with JUST my LAN interface connected and am still seeing the memory leak issue (was up to 1.5GB today).

Is there anything that I can do further to help diagnose this?

I'll have to get a version together that logs all the memory allocations - that way I might be able to track down which part of the code is doing it. I'll need a few days to get enough time to make that kind of change though.

Additionally, I've been away for a few days and came back today to find that late on Sunday night the 434 Transmitter had "stopped" - there was an event in the event log saying this.

However, there were no further events, even though I know that there would have been xPL messages sent since then to transmit stuff. So it appears that xPLRFX does not attempt to recover the Transmitter? Otherwise would I not see additional events in the event log where it had tried to transmit again and failed?

If the transmitter stops, it should start again straight away, or at the very least it should keep retrying. It may be that the restarts are not logged (I think it only does one to avoid filling the log). I'll make sure those items are added to the logging in the special build too.

[martynw]

Cheers Mal,

I'm now running the other debug build that you sent me a while ago to try and track down the keyfob issue, so maybe that will show something too if/when it does it again.


Martyn

[martynw]

Hi Mal,

I've uploaded a log file from the xPLRFX build you sent me a few weeks back to http://www.aceshigh.net/xplRFX-050210.zip (it's about 4MB).

This has been running since the 2nd (I've been away since then) and has been running as a console app, not a service.

I came home today to find that the memory usage had grown to nearly 2GB (this was at around 1pm), but interestingly a few hours later I noticed that it had dropped down to around 50K, almost like the app had restarted - this is similar behaviour that I see when it's running as a service, it will crash but then I've set the service to automatically restart.

But since this was running as a console app, I certainly didn't restart it, so I wonder how / why it seemed to recover without crashing?

Also, at 5.47pm, the Transmitter apparently stopped responding, restarting the app brought it back to life. In the log file I noticed that this coincided with processing 3 xPL commands in quick succession. The Transmitter sent at least one of the commands (since the outside light concerned turned on). Perhaps this is an area to look at?

Cheers,

Martyn

[martynw]

Hi Mal,

(I know you're busy with the Z-Wave stuff right now, so no rush on this)

About a week or so ago I un-ticked the "use handshake cable" on the Lan 434 transmitter and since then haven't seen any supposed transmitter failures. It might be coincidence I guess, but I was seeing failures pretty much every day.

I wonder if it's some sort of timing issue when sending multiple commands at once?

What are the ramifications of not having the "use handshake cable" box ticked? I know that the Lan Interface has an internal cable already connected, but for my other 434 receiver and transmitter I've never actually connected up the cable to be honest.

Also, is it possible to add something to the xPL messages? I think it would be useful to be able to identify which transmitter / receiver transmitted or received a command so an additional item in the message e.g. rfxcom=COM3 or rfxcom=rfxcom.domain.etc:10001 would be great.


Cheers,

Martyn