=hi Pestus thanks for the quick reply.
So do you connect your PRT3 by USB directly to the vera?
Yes. USB is ideal. You’ll need a cable with one end as Type A, and the other end as Type B. USB - Wikipedia There’s a certain way you have to program the PRT3 and the EVO192 to make it all function properly, but this is well documented in the instructions for the plugin. It can coexist with the IP150 quite well. It’s extremely fast and reliable integration.
Is there a way to send a force-stay command to EVO192? What I would like to do is to activate a scene when I go to sleep at night to have all my electric external shutters closed and then force-stay the alarm even if I have forgoten to close any of my manual external shutters. In the morning all my external electric shutters open at a predifined time but only after the alarm has been disarmed automaticaly by a scene.
The low level Evo API doesn’t have the notion of Force-Stay
You would probably need to handle this in the Evo programming itself. You can have arming modes switch to force arming, and specific codes set to do it too. Then, when the Vera tells it to stay arm, the Evo will handle the logic you are requesting on it’s own.
[quote=“guessed, post:89, topic:165163”]The plugin itself deliberately doesn’t save PIN Codes, as it wouldn’t be secure.
Users wanting to do this can use [Advanced] Scenes to declaratively specify Arming/Disarming with PIN. In this case, it’s the Scene that “holds/stores” the PIN Code.
You can also formulate URL’s that have this information in order to integrate from “outside” of Vera itself.
CAUTION: Anytime you save a PINCode like this, it goes into the Vera config files. When these are backed up to MIOS servers, which aren’t protected in any significant manner, the PIN Code is accessible there also (to any Hacker able to get in).[/quote]
I can not find the option to add a PIN on the advanced tab when I select requestdisarm from Alarm Area 1. Any help?
Never mind, found it. It showed up when I pressed the disarm button on the device “Alarm Area 1” on the dashboard.
Thank you for your quick replies.
Hi!
Because I start this topic to summarize the experience gained paradoxical plugin. A lot of questions have already found the answer, but you have not yet. 1 The surface treatment vera3 programmed sensors that I will integrate the paradoxical evo panel to see the status of the keypad?
I’m not sure what you’re asking. You may want to rephrase it so that the language translator you’re using has a better chance of understanding how to translate the text of your question.
I would like to Vera3 programmed motion controller, door contact status, see the Paradox system zones.
thanks 
The Paradox plugin will
[ul][li]Expose all Alarm Zones to Vera.[/li]
[li]Expose the Arming state, of each Alarm Area/Partition, to Vera[/li]
[li]Allow Zone, and Arming state, changes to be used as Event Triggers in Vera scenes[/li]
[li]Allow Vera to change the Arming state of each Panel Area/Partition[/li]
[li]Allow Vera to request Fire/Ambulance and Panic Alarms[/li][/ul]
Thank you very much your answer!
Our recommended solution is quite drastic. I am working on a sophisticated method to solve. Every movement Vera motion sensor, door sensor separate zone is shown on the paradoxical status of the panel 192 EVO. It is likely that the PRT3 virtual inputs to work. Can you offer any help?
Thank you very much in advance!
This is the only “virtual” support I added to the Paradox Plugin:
http://forum.micasaverde.com/index.php/topic,2492.msg129141.html#msg129141
Depending upon what you’re doing, it may or may not help. That said, I’d use Paradox sensors WELL before I use Z-Wave equivalents (and attempted to map them into my Paradox).
The difference in quality, and reliability, between these types of sensors is night-and-day (with the Paradox ones being extremely reliable)
NOTE: This thread will be merged with the main Paradox Plugin thread, to keep everything together (and because it’s mostly repeated content from that thread)
I randomly get the Failure in Request-Area-Label Response, communications error AL001 after a day or two of operation. It is NOT fixed with a reboot of the Vera. Only way to fix is to turn unplug the power. Is there a log of some sort I can get to you guessed that can help diagnose the problem?
The only time I’ve seen this is during successive, rapid, restarts of Vera. In the cases I’ve diag’d so far, it seems like Vera has the Serial port tied up and isn’t letting the plugin perform it’s startup functions correctly.
The AL… command is the first that I fire off during startup, so it’s the error you’ll see when the Plugin has problems with it’s IO.
If you’re seeing this frequently, then your Vera is restarting frequently, probably frequently enough that it’s jamming the IO channel to the Paradox.
Standard LuaUPnP.log file will give you the clues as to why your Vera is restarting, but you’ll need to capture it (with Verbose logging enabled) at a time that covers the period of the restart itself… otherwise the log isn’t all that useful (as it’s akin to saying that something happened, but it doesn’t tell you why)
Normal/generic recommendations apply before going too deep:
a) Disable/remove ERGY if you’re running it, it seriously destabilizes most systems.
b) Remove any unused Plugins/Devices that you’re not using.
c) Install SysMon Plugin to record/log the system usage
d) Turn off Auto-Discovery of Network devices
e) Run the latest Firmwares in each of the relevant stacks (eg, latest UI4 or UI5, only)
Minimizing frequent restarts should minimize the occurrence of this problem (at least, as far as I’ve ever seen it). That said, I’ve never seen a case where “reloading” Vera doesn’t work-around the problem when it occurs, but it’ll be best to start by reducing all th background issues causing your Vera to restart, since things are easier to look at without the clutter.
Hi guessed,
Thank for the thoughtful and in-depth reply. Would a lot of Luup restarts hang the paradox IO? I have been testing/changing some conditions in PLEG recently and that meant a lot of Luup restarts when I click the red “SAVE” button at the top right. Also, do you say “Auto-Discovery of Network devices,” is that the setting called “Auto detect devices on my home network” under the Setup and “Net & WiFi” tabs? My vera is not frequently restarting according to the SysMon plugin.
[quote=“93732, post:156, topic:165163”]Hi guessed,
Thank for the thoughtful and in-depth reply. Would a lot of Luup restarts hang the paradox IO? I have been testing/changing some conditions in PLEG recently and that meant a lot of Luup restarts when I click the red “SAVE” button at the top right. Also, do you say “Auto-Discovery of Network devices,” is that the setting called “Auto detect devices on my home network” under the Setup and “Net & WiFi” tabs? My vera is not frequently restarting according to the SysMon plugin.[/quote]
Yes, that’s what I meant by a lot of Restarts. It doesn’t matter when they were user-initiated, or due to one of the bugs in Vera itself, they’re both a “restart” from a Plugin’s perspective… Not sure which component gets jacked up at that time (the PRT3, Vera’s ser2net driver or the LuaUPnP talking to ser2net) but something comes amiss if there are frequent enough restarts… and I’ve never managed to get to the bottom of it.
If you find that the Errors continue at high frequency after you’ve finished all of your Scene edits, then we should look a little closer.
Yup, the “Auto detect devices on my home network” is the option I was looking for. I was going from memory (which, clearly, isn’t as good as it used to be). Generally in a “stable” Vera, these options can be turned off since they generate a bunch of unnecessary background activity and logs. In the case of this option, it’ll “act” each time a DHCP request is detected on the network (each iDevice, Android device, laptop, etc, etc that attaches, and each time they do) and it writes logs (and has to “do” some internal work) each time these devices show up on the Network (Vera probes them…)
Hi guessed,
I am still on my quest to solve the instability with the Paradox Alarm plugin. When it is working, things are fantastic! Response is fast. However, the plugin will “crash” and give me the AL communication error within 24 hours of use. It would require a soft reboot to work again. These are the things I have unsuccessfully attempted to diagnose/fix the crashing plugin:
- Configure the Vera to reboot daily—this did not increase the plugin reliability.
- Confirmed with sysmon that my system is not rebooting repeatedly.
- Unchecked “Auto detect devices on my home network”
- Confirmed that ERGY is not activated.
- Reset my Paradox panel by first removing the battery and then the AC Power.
- Started from scratch: Excluded all my devices, factory reset my VeraLite, reset the Z-wave network, re-paired all my devices, installed only the Paradox plugin and PLEG app. – still crashes.
Here is my hardware list:
- VeraLite with Firmware 1.5.622.
- Paradox DGP-848 with multiple wired door/window/glass break/motion detectors.
- PRT3 v1.2 attached to VeraLite via USB
- Magellan RTX-3 with a few wireless motion and door detectors
??? ??? Do you have any other ideas where to go from here? I am debating purchasing a Vera 3 in hope that its increased memory may help (or that it uses a different USB chip).
Can you grab a log file covering the period where it gets the error?
ie. Before, during and after
Verbose logging will need to be enabled in Vera’s UI so we can get all the low level details during the issue.
If it’s hard to catch, then you’ll want to temporarily remove the “Upload” option on the Log files, so Vera will write the logs and keep versions of them locally for longer. For this, you will need USB logging enabled, so we don’t create any other memory issues in Vera (they’ll be big)
I’ll also want a copy of running “[tt]logread[/tt]”.
Once you have this, you can PM me with where to get it from, or you can attach it here but you’ll need to scrub the logs first to remove the PII in it (URL’s, PIN Codes, HW_Key’s etc)
I’m assuming that you have:
[tt] PRT3 <— short USB cable —> Vera[/tt]
and have also tried swapping out the USB cable. No USB extenders should be present, and you should minimize USB Hubs. If you are using a HUB, it will need to be a powered HUB (ie. not Bus-powered) since Vera’s USB ports appear under-spec.
BTW: Really appreciate the level of detail you’ve gone to here in the self-diag, it helps a ton to get that kind of prep.
[quote=“guessed, post:159, topic:165163”]Can you grab a log file covering the period where it gets the error?
ie. Before, during and after[/quote]
Okay, I will work on getting you a verbose log. Is there a variable that I can monitor using PLEG so that I can be notified when the AL communications error occurs?
[quote=“guessed, post:159, topic:165163”]I’m assuming that you have:
[tt] PRT3 <— short USB cable —> Vera[/tt][/quote]
I have it attached as follows PRT3 <— 6 ft USB 2.0 cable ([url=http://www.monoprice.com/Product?c_id=103&cp_id=10303&cs_id=1030301&p_id=8616&seq=1&format=2]Monoprice USB Type-A to USB Type-B 2.0 Cable - 28/24AWG, Gold Plated, White, 6ft - Monoprice.com) —> VeraLite
No USB hub or extenders. Although I will use a powered USB hub when using USB logging.
I will try switching to a different USB cable and report back.