Charmed Quark Systems, Ltd. - Support Forums and Community

Full Version: Elk Driver Waiting to Connect in 3.02
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I have recently upgraded to CQC 3.02 (from 2.3.3). I followed the procedure in the release notes and it appeared at first that all went well. It did not take long to realize that the Elk driver was not online. From the driver status screen in the admin console the driver status alternated from "waiting to connect" to "waiting for comm resource".

For grins I verified that no other device had the M1's IP address (Elk was the sole owner of its address).
I could ping the Elk M1XEP without problems.
I could reach the Elk panel from RP with no problem.
I could telnet (using port 2101) to the M1XEP and see status coming from the panel.

I moved my master server from it's normal home (2.3.3 version) a WHS box to a generic XP machine with no change in results.

At this point I decided to go backwards and re-install the 2.3.3. I did this on the XP machine since that's where I was and BAM the Elk driver connected and all is well.

So now the question. Does anyone know if there any Elk panel dependencies when upgrading to 3.02? The firmware version on my panel is 4.3.8 which based on the CQC support pages should be ok. Are there any new issues with WHS? I had no problem installing 2.3.3. With 3.02 I initialy recieved a message saying I did not have permision to run this program. I copied the installation files to the desktop and the install proceded without issue.
I'm accessing it OK from 3.02 via ethernet. Latest elk software for the panel and the ethernet board. Vista 32 bit. Make sure Enable non-secure port is setup in the Elk under tcpip settings. And make sure ElkRP is not connectedSmile
Make sure that you don't have any garbage in any of your custom values. A firmware error somewhere back allowed that to happen. They all should be numeric values, but they could get some text in them by accident. Support for the custom values was added in the run-up to 3.0.
So you can have three data types; Number, Timer and Time of Day. When I installed 3.02 I said 0 to the number of custom settings that I wanted CQC to monitor. Does it still matter then? I currently use three custom settings on my Elk, one timer and two Time of Day. In the time of day values I do see "AM" after the time, is that what you mean? What about the colon?
It's formatting the value for you when you say it's a time value. I think though that probably all of them will get seen, even if not all are stored. So make sure the rest are zeroed out if possible.

If that doesn't help, flush the logs, put the Elk driver into verbose mode, and see what shows up in the logs that's making it unhappy.
electriclight Wrote:The firmware version on my panel is 4.3.8 which based on the CQC support pages should be ok.

I had problems like you describe with 3.0.2 until I upgraded my elk's firmware to *.20 from *.8.
Some firmware based features were added in 3.0. It checks the firmware and enables certain things or not. There's always a chance that could be not working exactly right. The rules are a little complicated because of the two separate branches of the firmware they've gotten into.

Any chance you could just upgrade to the latest and avoid the problem?
I've been looking at the change history for the M1 firmware and belive that would be a good choice based on SamVimes2 comment. I'll give that a try and report back.
Success!

Last night I upgraded the Elk M1 to firmware version 4.5.20. The results were as expected; the CQC Elk Ethernet driver connects without issue.

This was quite an upgrade process and was not without injury so I’ll post this just as a reminder to future folks that might be in my predicament. To get started, I was running RP version 1.6.12 which needed to be upgraded to version 1.6.26. Reminder number 1; make sure you backup your RP database (especially if you have a non default named database). Elk provides many warnings about this as the database is relocated during this upgrade. This part went smooth and without incident.

Next the M1 panel itself was upgraded. I was at bootloader 3.1.13 and firmware 4.3.8. Following information in the release note I upgrade the bootloader to version 3.3.2 and the firmware to version 4.5.20. This went smooth, without incident and it fixed the CQC driver connect problem. :-)

Next was the M1EXP that was d o w n rev. This is where I missed a step and will have to do some homework to see what the recovery path is. I was at boot version 1.0.1 and firmware 1.1.0. Why I missed this, I├ó┬Ç┬Öm not sure, but I should have upgraded the application first, then the bootloader and last the application again. I did the bootloader first followed by the firmware. At this point everything is running but instead of being at the latest firmware (1.2.14) I├ó┬Ç┬Öm at 1.2.0 (I did not know I even had that version in the Elk directory). The scary part is that the bootloader version displayed in RP says ├ó┬Ç┬£erased├ó┬Ç┬Ø. So I├ó┬Ç┬Öll have to fix this.

I know, long update, just wanted to get the info in a place so that someone else doesn’t make the same mistake. Good thing, main problem is fixed!