Texecom Premier - COMIP protocol issue

[secureiam]

so panel was sending to 192.168.1.125 on 10001, worked in SIA or contact ID, not shown texbase, but that would be the next steo.

hope this helps, I have run on a version 9.02 but cant be sure I have ever run a version 8 panel, but didn't see anything in the old panel info in wintex as to it being updated so should work.

without looking into it any further, not much I can say, don't need leading zeros for it to work.

check its setup correctly, stop the coms and ip and restart them, should see the 5 as in receive data snap shot.

I setup a panel and montex and texbase from scratch, took longer to boot the laptop so I could access the panel, than it did to setup and test.

 

[nickthesloth]

Sorry I didn't mean to sound blunt - frustration setting in by that point

I'll go through and set it up again this weekend and compare with your settings for good measure. I have firmware 8.22 to try out at some point once I've devised a flashing interface, if all else fails. Which as a bonus supposedly adds Richochet support as of 8.15.

When you do a test call from the panel, does it stick on 'please wait' for any length of time? It's hard to tell from the keypad on mine if its actually trying to do anything when its at that stage, whereas 'fast format' goes through IP connecting, sending etc, all quite quickly.

 

[secureiam]

usually if its initialising the module isn't corretly set up, or test calls not enabled on the arc.

 

[nickthesloth]

I've started again entirely, wiped the alarm and software installation, but no dice.

Upgraded the panel to 8.22 but no change, and this firmware has actually broken the polling timer. Set it to something and often it changes to another odd value when pressing yes. If you manage to get it to set to 1 minute, and the polling delay is set to 15 on Montex, when it does the poll and tries to change to the server provided value, it interprets it incorrectly and you get 68 minutes.

So... does anyone happen to have another v8 firmware they could send me? Or 9.02... I think I need to change the eeprom/nvm for a 256k chip for v9+, but that's not a problem.

 

[secureiam]

the answer to our question the poll timer does change, 5mins when the poll is due and your in engineering, then goes back to 15 mins, although on some verions I think there was adiiferent time involved but couldn't tell what it was off top of my head

 

[nickthesloth]

Something is going a bit screwy with the way it interprets what is sent back. Will email Texecom again tomorrow and ask for a different version, and ask if this is a known issue with 8.22. Wish they supplied proper release notes with the version they sent me.

 

[secureiam]

haven't seen the data so cant comment last time I used it on the old premier the panel was a 9.02

 

[nickthesloth]

Right, this is now sorted, I figured I'd post back in case anyone else runs into this issue.

It turns out, if you don't know the engineers code to these alarms, wiping the EEPROM out and letting the alarm reset itself (re-writing the blank EEPROM NVM) only 'mostly' works...

Noticed in Wintex the serial number of the alarm was all zeros. Comparing the original EEPROM data and the re-written reset data... there was a chunk of 'something' missing. The serial number and probably something to do with the Contact ID and SIA protocols must have been in that data, because having now been able to retrieve the engineers code from the original data, write that back to the EEPROM and reset again, everything now works.

I've also upgraded to 9.02 which has fixed the polling interval problem introduced in 8.22. Upgrading to v9 supposedly needed a 256k EEPROM, which is what I had written my data back to. I could pull it back out and see if that was actually necessary if anyone is interested.

What I would say then to sum up - wiping the EEPROM chip (or simply bunging in a blank one if you don't have a reader/writer) will get you a working alarm panel, but Contact ID/SIA will be broken as a result. I've seen posts elsewhere stating you can just put in a blank 256k chip before upgrading to v9... I'm guessing they hadn't used Contact ID / SIA when they did that.

Now on to setting up Texbase.

 

[secureiam]

Used to get the blank nvms when they were locked, and use wintex to send the data, wintex can send the reporting codes, you can even change them into wintex to some degree so that function a specific way in the panel, when you look at the reporting codes you have the option to load the default ones, always a good idea, on a version of the elite panels they messed up with the repoting codes and you had to load the defaults in winex and send them back to get them setup properly.

 

[nickthesloth]

Yeah, I've found the reporting codes issue and set those up in Wintex as you say sending the defaults.

I wonder if its v8 that just doesn't like the protocols working with a wiped EEPROM, perhaps v9 behaves differently. Either way - I have the serial number present and working protocols now, so I'm happy. I should have looked at the data harder in the first place to see the engineer's code that was previously set and I'd have avoided this faffing. As the panel otherwise worked fine I didn't think much of it.