I set this up today with a Qolsys 4 Panel with software version 4.2.1, and I'm getting the Socket Received Failed 192.168.1.x:12345 at least once per minute. Strangely, everything otherwise seems to be working, though motion sensors tend to be very finicky. Any known solution to the socket errors yet?
-Hank
This is an edited version of the driver that clears out the socket error.
Thank you! This seemed to fix the problem, though there is a parenthesis that I had to add that was missing in the code on line 143 to make it work. After I updated the driver code, I rebooted, and it seemed to fix the problem.
If this code works for everyone, probably makes sense to update the version in the Hubitat Package Manager, because that's how I installed these drivers to begin with.
THANKS!
Thanks for the link to fix the socket error. @hankle, thanks for the tip to add the ) to line 143. It seems to be working correctly after I rebooted my Hub.
I saw you were able to change the requirement to send the arm code if secure arming is disabled. Is that something you could help me out with?
Have you done anything with adding new devices? I have a couple that are not in the current code.
Hopefully a simple question with a simple answer. How do I arm the Qolsys iq4 panel in away mode webcore? I have all the integration working but I can't seem to set Alarm_Mode_Partition_0 to arm_away in webcore.
I have no problem setting it to arm stay because I can set a user code with it, That option doesn't seem to exist with Arm_Away
armAway( partition_id, String bypass = "No", delay = 0, user_code = 0 )
I don't arm/disarm my panel through HE so I haven't tested this in a while, but it ought to work. armAway(0) should be all that's needed unless your panel is set to require a user code to arm, although you probably want to set a delay.
I don't recall if 0 uses the default exit delay setting or if it really sets it to zero seconds (probably not what you would want unless you're already out of the premises before arming).
I do need a code to disarm on the panel. Here are the screenshots in webcore. As you can see, I have parameter options for armstay, but not armaway so armaway fails for me.
I think the issue is that I cannot pass parameters for arm away in webcore like I can for arm stay. Is there a change to the code that can be made to allow this?
Makes no sense (to me, anyhow), but I can reproduce it here. I think it's a bug in Webcore. I don't see why armAway should be treated any differently than armStay.
I am glad you were able to reproduce it and its not just me. 
Any idea how I could go about getting this fixed? Are you sure it is a Webcore bug?
Pretty sure. @nh.schottfam can you take a look at this? Under "Commands available to all devices", the items are incorrectly labeled. Arm Away and Disarm should be custom commands. initialize should not custom
So what is going on is this custom device is overloading built-in commands.
Hubitat in capabilities (Driver Capability List | Hubitat Documentation) has commands for:
- armAway()
- arrmHome()
- disarm()
Note that these built in commands take no arguments. webCoRE is using the predefined command to take precedence.
The above screen shot on 'Commands available to all devices'
is showing that commands
- alarm
- armStay
- initialize
are custom commands, so webCoRE found their arguments (as they are custom)
You can look further down in your list of commands for those devices if in addition to the predefined commands, there are custom commands in the list (further down)
I can look at this more, but it really is bad form to try to redefine pre-defined commands for capabilities. Inherently it creates ambiguity and it gets worse if one uses device variables. The IDE when editing a piston can have a hard time sorting this out.
I would bet if the overload command names were changed to
- pArmAway(xxx)
- pArmHome(xxx)
- pDisArm(xxx)
things would work as this would remove the overloading.
There may be other options, but would have to see what else the IDE is showing in the list of commands.
But I'm not. armAway is a command for a driver with the "SecurityKeypad" capability. This driver does not implement that capability. The only capabilities declared are Initialize, Refresh and Actuator.
What you are saying would make perfect sense if this was a "SecurityKeypad" device.
Seems to me that Webcore is not considering the capabilities of a device when forming the commands list.
there is some history here.
not all devices define their command correctly - still seeing this today that they don't have the proper description.
webcore has built-in command to deal with this.
webcore also has device variables, so the IDE does not know what type of device it may be acting on.
So webcore has built-in commands. You are define custom commands, and using the same name as built-ins. it is ambiguous, especially with device variables.
So yes, this is what is happening.
OK, then shouldn't they be the ones that don't work correctly?
So if my (correctly written 
) driver implements a command named off( int foo ), it won't show up correctly in the command list because off() with no arguments happens to be a command for a driver with the "Light" capability, which has nothing to do with my device's capabilities?
How would a driver author even know about webcore's "built-in" commands?
Ok, but that's really a different scenario (weak vs strong typing). In this case, the device type specified in the "with" is known at design time, is it not?
I suggest you use device variables in webcore
My points may become clearer
I will when I have some time to play around. But that doesn't address the issue raised by user4934. There is no device variable being used here.
Isn't the device type known here: (otherwise, how would it know to display the custom commands defined by that device)?
I am not a developer but it sounds like Arm Away conflicts with the built-in Hubitat Arm Away command that is used for the Hubitat Safety Monitor? Changing the groovy code variable to something different will fix it?
Not exactly. There is no problem or conflict within HE.
Device drivers must declare what device "capabilities" they support. Capabilities are defined by the HE platform and define commands and/or attributes that a device supports. A device driver can implement any number or capabilities, as needed for that particular type of device.
For example, a device that supports the "Switch" capability must implement the commands on and off and the attribute switch which can have values of "on" or "off". A device that supports the "SwitchLevel" capability must implement the setLevel command and the level attribute.
Device drivers can also implement custom commands and/or attributes if no combination of capabilities exist that completely describes the device in question.
As nh.schottfam opined (and I totally agree), it is bad form to implement a command (or attribute) differently than how it is defined by a capability that you are using (emphasis mine). Capabilities that a device driver does not implement are totally irrelevant to the proper functioning of a device that uses the driver.
Except, that apparently for historical reasons related to improperly written drivers, webcore does not take into consideration whether a device implements any given capability and checks a driver's commands against a list of (undocumented?) commands internal to webcore. So even though my driver does not implement the "SecurityKeypad" capability, webcore still thinks there is a conflict between the armAway command my driver implements and the armAway command that SecurityKeypad implements, and chooses its own definition rather than the one in the driver. This causes the behavior you ran into.
In my opinion this is a problem with webcore. Software isn't perfect and sometimes you have to do things that aren't optimal. Maybe the pros outweigh the cons (at least at the time it was implemented). Whether it can be fixed or not, I have no idea.
Has the doorbell device been added to your code yet? Or do I need to do something?
