Varia not responding to PKEYP- commands
Posted this on the facebook forum as well @Marc Scheibein here is an example of what I'm referring to,
Here is the text log from the controller, the 1st 10001 device is a varia TP. The one that comes online later in the text is an MT1002:
Line 1 2024-03-01 (10:50:49):: Input Status:Pushed [10001:15:1] - Channel 4
Line 2 2024-03-01 (10:50:49):: Command To [10001:15:1]-[PKEYP-]
Line 3 2024-03-01 (10:50:49):: Input Status:Released [10001:15:1] - Channel 4
Line 4 2024-03-01 (10:50:52):: String From [10001:1:1]-[PKEYP-1234]
Line 5 2024-03-01 (10:51:00):: String From [10001:1:1]-[SLEEP]
Line 6 2024-03-01 (10:51:00):: String From [10001:1:1]-[WAKEUP]
Line 7 2024-03-01 (10:53:19):: Device [10001:1] is Offline
Line 8 2024-03-01 (10:53:43):: Device [10001:1] is Online
Line 9 2024-03-01 (10:53:43):: Command To [10001:1:1]-[LEVON]
Line 10 2024-03-01 (10:53:43):: Command To [10001:1:1]-[RXON]
~~
Line 79 2024-03-01 (10:53:48):: Command From [10001:1:1]-[G4WC-"Device 10001",192.168.1.116,5900,1]
Line 80 2024-03-01 (10:53:51):: Input Status:Pushed [10001:15:1] - Channel 4
Line 81 2024-03-01 (10:53:51):: Command To [10001:15:1]-[PKEYP-]
Line 82 2024-03-01 (10:53:51):: Input Status:Released [10001:15:1] - Channel 4
Line 83 2024-03-01 (10:53:56):: String From [10001:15:1]-[PKEYP-1234]
Line 84 2024-03-01 (10:53:56):: Command To [10001:1:1]-[PAGE-Tech_Page]
and the code to run that is here. Just create a button on the main page with, TP port 15, channel 4
and make another page called Tech_page.
the page never gets called by the varia.
Comments
I don't follow the facebook forum, so don't know what's been said already, but I see you're using the old (G4 compatibility) commands. Have you tried using the new ones to see if those work?
PAGE > ^PGE
PKEYP > ^PKP
edit: typo
DEFINE_COMBINE isn't recommended for combining devices anymore. I didn't have much luck with it when I used it (15 years ago). Device arrays are recommended for combining devices, with Netlinx that has always worked better, DEFINE_COMBINE is an (expanded) leftover from the Axcent days.
If I remember correctly, virtual devices by default only maintain the state for 1 port. If you want to use port 15, you have to set: SET_VIRTUAL_PORT_COUNT(vdvTP, 15) and SET_VIRTUAL_PORT_COUNT(vdvTP_TECH, 15). Not sure if this applies to device combining which are already defined.
See attached txt file for what I copied from the Diagnostics window, first without the 'SET_VIRTUAL_PORT_COUNT' command and the second part with that command.
>
This line confuses me a bit. Seems like you got that from 'Notifications', so must be true. It used to be that when you send PKEYP-, the response was KEYP-, so without the leading 'P'. And the response always came back on port 1, no matter what port you send it to. Because it bugged me (a bit...) I tested with a NX-1200 and a MXT-700 (G4)
That is how I remember it. Don't have a MT-1002 at hand to test with, so don't know about that. If I change the string_event from the 'vdvTP_TECH' to the 'vdvTP' device, it works for me (because my response comes back on port 1)
The reason for my previous post, was that when AMX moved from G4 to G5, some of the commands were a bit off, especially the keypad/keyboards return string was wrong. Could be fixed now.
Good luck with this
The old keypad/keyboard commands still work. The newer commands are extended, with the ability to name the keypad, give a default text into the text field, a free defined reply keyword, the port for the returning keypad input can be defined.
Without that parameters, they return of a keypad/keyboard comes back on port 1, whatever port you send the command to.
@floydcg the route cause is that your data_event listens to vdvTP_Tech, which is 33501:15:0. The Varia, and by the combine to the virtual device, returns the Keypad input on Port 1
Line 1 2024-03-04 (10:28:47):: Input Status:Pushed [10001:15:109] - Channel 4
Line 2 2024-03-04 (10:28:47):: Input Status:Pushed [33501:15:109] - Channel 4
Line 3 2024-03-04 (10:28:47):: Command To [33501:15:109]-[PKEYP-]
Line 4 2024-03-04 (10:28:47):: Command To [10001:15:109]-[PKEYP-]
Line 5 2024-03-04 (10:28:47):: Command From [33501:15:109]-[PKEYP-]
Line 6 2024-03-04 (10:28:47):: Input Status:Released [10001:15:109] - Channel 4
Line 7 2024-03-04 (10:28:47):: Input Status:Released [33501:15:109] - Channel 4
Line 8 2024-03-04 (10:28:57):: String From [10001:1:109]-[PKEYP-1234]
Line 9 2024-03-04 (10:28:57):: String From [33501:1:109]-[PKEYP-1234]
Line 10 2024-03-04 (10:28:57):: Command To [33501:1:109]-[PAGE-Tech_Page]
Line 11 2024-03-04 (10:28:57):: Command To [10001:1:109]-[PAGE-Tech_Page]
After changing your data_event listening to vdvTP, it is working as expected.
crosschecking with a Modero G5 panel, the Modero returns the keypad reply on the port it got the command to open the keypad. At this point, I must admit that I got confused, because I always assumed they got returned always on port 1 (also for backward compatibility to G4), as long as it is not mapped to another port by the command parameter. Otherwise, using other device ports for the keypads/keyboards require to have a element on the port number you want to use for the keypad replies, so the panel will raise its port count.
With the G5, the keypad/keyboard commands were extended, including to map a keyboard/keypad reply to another port. You have to configure this by the command with some parameters (Detailed for PKEYP see Varia Programming guide, page 72):
'PKEYP-;;;;15' // no other predefinitions for the private keypad, just mapped to port 15
Line 3 2024-03-04 (10:48:47):: String From [10001:15:109]-[PKEYP-1234]
Line 4 2024-03-04 (10:48:47):: String From [33501:15:109]-[PKEYP-1234]
In most applications, if I need different keypads/keyboards to detect, I call them with parameter #4 set to another returnprefix:
'PKEYP-;;;PKEYPTECH-'
Line 8 2024-03-04 (11:47:17):: String From [10002:1:109]-[PKEYPTECH-44555]
So I don't get into trouble with the port assignments.
I will check with Harman if the Varia's behavior with keypad/keyboard replies is working as designed.
little update: this is also an issue in the official 1.11.29 firmware of the Varias.
Changing the port/vdvTP assignment did in fact resolve this one on 1.11.40. Thanks for your help @Marc Scheibein