I am in GMT and my log messages show the correct time.
I can connect with Wintex and can also connect with the iOS app.
Hi, I have the integration working fine but I have one zone which I’m using as a contact sensor to display whether the garage door is open or not. As I say all other sensors are working fine. This zone has been setup to not trigger the alarm or stop the alarm setting when it’s open. Its been setup as a latch key with the attribute of Keytube/monitor only. Does anyone see a problem with this and notifying home assistant? Thanks.
Yes, you should be able to have zones that are permanently omitted from all sets, and they should still appear in this integration allowing you to do something based on it changing.
Not sure I’d do it as a latch key though and that’s something you’d probably need to try with a bit of trial and error. To quote the documentation:
This zone type can be used to arm and disarm one or more areas. When the zone is activated, the areas assigned to the zone will arm. When the zone is secured, areas assigned to the zone will disarm. Tamper faults will not arm or disarm anything, but will cause a Tamper alarm.
This means that opening and closing the garage door would arm/disarm the alarm, which seems a surprising way to protect the garage contents!
Personally, if all you want to do is use the zone to monitor in HA and nothing else, I’d just create it as a guard zone type, and omit from Part 1, Part 2, Part 3 so it won’t play any part in the alarm guard process:
I do this myself for a certain zone that I don’t want to alarm on, but I do want to see the status of in HA.
(disclaimer: I may have entirely misunderstood what you are trying to do here!)
Ah, ok thanks. Perhaps I have it set up incorrectly. Essentially I just want to use the telecom alarm panel as the gateway to HA for this contact sensor. I am going to use it to determine whether the garage door is open or not. I’d be ok if it triggered the alarm but because I have the garage door open when setting the alarm a “normal” zone would stop it arming. Any suggestions how I should configure the zone? As I say I’m happy if it triggers the alarm but I need to be able to set the alarm with the contact open. I’m also fine for it to be outside of the alarm system, so to speak. I’ll just be using the sensor to determine in HA if the door is open and trigger the lights in the garage. It would also make the icon on the dashboard be a bit more accurate i.e. I’ll know for definite when the door is open. Thanks.
Sure, so you can set this zone up as a “guard access” zone (immediate alarm on open) or extry/exit (timed entry before alarm sound). (“guard access” allows the zone to be in alarm during the set process)
e.g. if you make the garage door an entry/exit zone, and then set the arming mode to “entry/exit”, then when you enter your code to set the alarm, it won’t complete the set until:
- The garage door is closed, and;
- Exit settle timer has expired (typically 5-10s)
Then, when you open the garage door, because it’s an entry/exit zone, the alarm will begin beeping for a code and will continue to do so until it is entered, or the entry 1/2 delay timer for the area has expired, at which point the alarm will trigger.
Thanks for this. Is there a way to keep it outside of the alarm, so to speak? I have just realised I’ll mainly be in the car and be reversing in etc… so the alarm may start to go off, I suppose I could up the delay time but I wouldn’t want to up it too much. Any suggestions please? Thanks.
I’m pretty confused by this, TBH.
If you want it to not be part of the alarm at all, just do the simple omit configuration that I posted further up and the garage door sensor won’t play any part in your alarm configuration, but will still appear in HA. As an omitted zone, it will not prevent you from setting the alarm, nor will it trigger when you open the garage.
1 Like
Thanks for your help, I’ll give it a try and see how I get on. Cheers.
Thanks - at least we know that is not the issue then.
I can also connect with Wintex 7.3.2 and the iOS v2 app.
Just started testing this after upgrading my panel from v3 to v5 firmware. I am using a comip on COM3 for HA exclusively, and have just installed a Smartcom for Wintex and cloud. I have a Premier Elite 640 with around 80 configured zones.
It was all working yesterday with all the wired zones configured. Today I added around 20 wireless zones, and now I get a repeating error in the logs. Last few lines here.
2021-12-18 00:01:10 - INFO: Fetched Zone 609: Workshop Door (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 00:01:10 - INFO: Fetched Zone 610: Workshop PIR (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 00:01:11 - INFO: Fetched Zone 612: Cloakroom PIR (Type: Entry/Exit 1; Areas: 1A)
2021-12-18 00:01:11 - INFO: Fetched Zone 613: New Shed Door (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 00:01:12 - INFO: Fetched Zone 614: New Shed PIR (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 00:01:19 - INFO: Updating all zone states...
2021-12-18 00:01:21 - INFO: Updating all area states...
2021-12-18 00:01:22 - ERROR: Unhandled rejection - RangeError [ERR_BUFFER_OUT_OF_BOUNDS]: Attempt to access memory outside buffer bounds
at boundsError (internal/buffer.js:75:11)
at Buffer.readBigUInt64LE (internal/buffer.js:88:5)
at Panel.getAreaBitmapFlag (/snapshot/app/dist/panel.js:198:32)
at Panel.updateAreaStates (/snapshot/app/dist/panel.js:376:37)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async Panel.loadInitialData (/snapshot/app/dist/panel.js:250:9)
at async Panel.start (/snapshot/app/dist/panel.js:239:9)
at async /snapshot/app/dist/index.js:73:5
I tried again with debug enabled. Are the timeouts normal? This is running on a Pi3b on the same vlan as the comip.
The final error look different to the one above.
2021-12-18 09:31:58 - DEBUG: Command 3 timed out (attempt 1, id: 82).
2021-12-18 09:32:06 - DEBUG: Command 3 timed out (attempt 1, id: 96).
2021-12-18 09:32:10 - DEBUG: Command 3 timed out (attempt 1, id: 98).
2021-12-18 09:32:23 - DEBUG: Command 3 timed out (attempt 1, id: 130).
2021-12-18 09:32:28 - DEBUG: Command 3 timed out (attempt 1, id: 134).
2021-12-18 09:32:32 - DEBUG: Command 3 timed out (attempt 1, id: 137).
2021-12-18 09:32:45 - DEBUG: Command 3 timed out (attempt 1, id: 169).
2021-12-18 09:32:52 - DEBUG: Command 3 timed out (attempt 1, id: 179).
2021-12-18 09:33:05 - DEBUG: Command 3 timed out (attempt 1, id: 213).
2021-12-18 09:33:16 - DEBUG: Command 3 timed out (attempt 1, id: 235).
2021-12-18 09:33:21 - DEBUG: Command 3 timed out (attempt 1, id: 241).
2021-12-18 09:33:45 - DEBUG: Command 3 timed out (attempt 1, id: 54).
2021-12-18 09:33:52 - DEBUG: Command 3 timed out (attempt 1, id: 65).
2021-12-18 09:33:55 - DEBUG: Command 3 timed out (attempt 2, id: 65).
2021-12-18 09:34:02 - DEBUG: Command 3 timed out (attempt 1, id: 74).
2021-12-18 09:34:07 - DEBUG: Command 3 timed out (attempt 1, id: 79).
2021-12-18 09:34:10 - DEBUG: Command 3 timed out (attempt 2, id: 79).
2021-12-18 09:34:15 - DEBUG: Command 3 timed out (attempt 1, id: 85).
2021-12-18 09:34:19 - DEBUG: Command 3 timed out (attempt 1, id: 87).
2021-12-18 09:34:23 - DEBUG: Command 3 timed out (attempt 2, id: 87).
2021-12-18 09:34:27 - DEBUG: Command 3 timed out (attempt 1, id: 90).
2021-12-18 09:34:32 - DEBUG: Command 3 timed out (attempt 1, id: 95).
2021-12-18 09:34:36 - DEBUG: Command 3 timed out (attempt 2, id: 95).
2021-12-18 09:34:39 - DEBUG: Command 3 timed out (attempt 3, id: 95).
2021-12-18 09:34:44 - DEBUG: Command 3 timed out (attempt 1, id: 99).
2021-12-18 09:34:45 - INFO: Fetched Zone 601: Utility Side Door (Type: Entry/Exit 1; Areas: 1A)
2021-12-18 09:34:45 - INFO: Fetched Zone 602: Garage Flood (Type: 24Hr Audible; Areas: 1E)
2021-12-18 09:34:48 - DEBUG: Command 3 timed out (attempt 1, id: 102).
2021-12-18 09:34:49 - INFO: Fetched Zone 604: Garage Main DoorContact (Type: Entry/Exit 1; Areas: 1B)
2021-12-18 09:34:49 - INFO: Fetched Zone 605: Kids Shed Door (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 09:34:50 - INFO: Fetched Zone 606: Kids Shed PIR (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 09:34:51 - INFO: Fetched Zone 609: Workshop Door (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 09:34:51 - INFO: Fetched Zone 610: Workshop PIR (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 09:34:51 - INFO: Fetched Zone 612: Cloakroom PIR (Type: Entry/Exit 1; Areas: 1A)
2021-12-18 09:34:52 - INFO: Fetched Zone 613: New Shed Door (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 09:34:52 - INFO: Fetched Zone 614: New Shed PIR (Type: Entry/Exit 1; Areas: 1C)
2021-12-18 09:34:56 - DEBUG: Command 3 timed out (attempt 1, id: 114).
/snapshot/app/dist/texecom/texecom.js:98
throw new Error(`CRC is invalid (${crc}), message: ${hexMessage}`);
^
Error: CRC is invalid (15), message: 744d097e017c02090f
at Texecom.parseBuffer (/snapshot/app/dist/texecom/texecom.js:98:19)
at Socket.<anonymous> (/snapshot/app/dist/texecom/texecom.js:32:18)
at Socket.emit (events.js:315:20)
at addChunk (_stream_readable.js:295:12)
at readableAddChunk (_stream_readable.js:271:9)
at Socket.Readable.push (_stream_readable.js:212:10)
at TCP.onStreamRead (internal/stream_base_commons.js:186:23)
I see that 1.1.9 has been released, but the release notes look out of date:
Any idea what’s changed / fixed?
Anyone any ideas how to stop this erroring please? Any help much appreciated.
2021-12-22 01:23:36 - INFO: Fetched Zone 610: Workshop PIR (Type: Entry/Exit 1; Areas: 1C)
2021-12-22 01:23:36 - INFO: Fetched Zone 612: Cloakroom PIR (Type: Entry/Exit 1; Areas: 1A)
2021-12-22 01:23:37 - INFO: Fetched Zone 613: New Shed Door (Type: Entry/Exit 1; Areas: 1C)
2021-12-22 01:23:37 - INFO: Fetched Zone 614: New Shed PIR (Type: Entry/Exit 1; Areas: 1C)
2021-12-22 01:23:45 - INFO: Updating all zone states...
2021-12-22 01:23:46 - INFO: Updating all area states...
2021-12-22 01:23:47 - DEBUG: Received area part arm flags: 15
2021-12-22 01:23:47 - DEBUG: Received area flags for Area 1D: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1
2021-12-22 01:23:47 - DEBUG: Received area flags for Area 1A: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1
2021-12-22 01:23:47 - DEBUG: Received area flags for Area 1E: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,0,0,0,0,1,0,0,0,1
2021-12-22 01:23:47 - DEBUG: Received area flags for Area 1G: 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,0,1,1,0,0,1,0,0,0,1
2021-12-22 01:23:47 - ERROR: Unhandled rejection - RangeError [ERR_BUFFER_OUT_OF_BOUNDS]: Attempt to access memory outside buffer bounds
at boundsError (internal/buffer.js:75:11)
at Buffer.readBigUInt64LE (internal/buffer.js:88:5)
at Panel.getAreaBitmapFlag (/snapshot/app/dist/panel.js:198:32)
at Panel.updateAreaStates (/snapshot/app/dist/panel.js:376:37)
at processTicksAndRejections (internal/process/task_queues.js:97:5)
at async Panel.loadInitialData (/snapshot/app/dist/panel.js:250:9)
at async Panel.start (/snapshot/app/dist/panel.js:239:9)
at async /snapshot/app/dist/index.js:73:5
2021-12-22 01:23:47 - DEBUG: Ending socket connection to panel
2021-12-22 01:23:47 - DEBUG: Socket connection to panel ended
2021-12-22 01:23:47 - DEBUG: Publishing to texecom2mqtt/status: offline
Well my Node Red monitoring just indicated a battery alert, if it has really chewed through the batteries in 1 month then it may have to go back to Hybrid mode where the batteries lasted several years… Ricochet is also showing the batteries are low.
Is there any capability in this solution to provide a keypad type interface? I’m able to do this using crestron protocol to an extent - you can issue key commands and read back the LCD text - the rest of this solution is much better than the crestron based one - but I do sometimes find it easier to make use of the keypad feature…
Even if it were just the ability to read back the LCD text that would be brilliant!
Of course! You’ll find the changelog in the link below.
Firstly, I love this integration, it’s made Home Assistant so much more helpful! Many thanks
I noticed on an old forum post that there were discussions for the “PC Control” output controls to be integrated into this project - is this still something planned?
Is there anyone who can debug this please on a 640 zone panel?
The plugin fails to start with this error below.
It does start up successfully if I delete most of my zones.
@a345623456 You may not have noticed, but a fix has been published for your specific issue - you might want to try it and see if it sorts your problem!
For myself, a question - my integration is still extremely unstable (perhaps worse than ever), with the add-on still silently failing (i.e. not reporting sensor status changes or alarm state changes), although in debug it’s logging the following every minute (with no changes at all to the values over the last 30-ish minutes of reporting) :
2022-01-02 20:35:02 - DEBUG: Updating system power...
2022-01-02 20:35:02 - DEBUG: Publishing to texecom2mqtt/status: online
2022-01-02 20:35:02 - DEBUG: Publishing to texecom2mqtt/power: {"battery_charging_current":9,"battery_voltage":13.49,"panel_current":612,"panel_voltage":13.56}
Is there any way to persist the add-on log between reboots, or access more of the log than is visible in the add-on panel in HA? This would greatly help me look back to where the issue begins and, hopefully, collect some more data on what the cause of my issue is?
I’m considering writing a node red flow to poll the add-on log for either lack of activity or any known error. I notice the addon sometimes stops working but doesn’t restart. I think it has a consistent error in the log which i can look out for and initiate a restart. Just needed to catch it failed again and figured something out.