VoxCommando
Help and Support (Using VoxCommando) => Other Plugins => Topic started by: jitterjames on May 04, 2013, 10:46:54 AM
-
This plugin will open up a whole new world of possibilities. With it you can control IP enabled devices such as GlobalCache products, network amps and TVs etc.
You can also use it to create a TCP or HTTP server which can be used to send commands to VoxCommando. Until now this was only really possible with UDP.
the plugin works well in my testing but be advised that it may undergo some design changes as we move forward, which means that future updates of the plugin may break your commands that use TCP plugin actions.
Unzip the TCP folder into your VoxCommando\plugins folder so that you have 2 files as follows:
[Attachments deleted. The TCP plugin and actions now come standard in VC. Any updates to the plugin will be included in each new release.]
-
reserved for sample and/or info
-
Here is the simplest command example I can show you, that uses the iTach to lower the volume on my Sceptre LCD TV:
<?xml version="1.0" encoding="utf-16"?>
<command id="620" name="sceptre vol down" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="">
<action>
<cmdType>TCP.Single.WriteLn</cmdType>
<cmdString>sendir,1:3,1,39808,2,1,96,24,48,24,48,24,24,24,24,24,48,24,24,24,24,24,48,24,24,24,24,24,24,24,24,3980&&192.168.0.134&&4998</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
<phrase>sceptre vol down</phrase>
</command>
This command uses the TCP.Single.WriteLn action which opens a connection, sends the data, appends a carriage return, and then closes the connection.
There are other methods that may be preferable that keep a connection open and can get feedback from the device...
-
Awesome!
Testing as soon as I finish work.
-
Initial testing on TCP Single Write and WriteLn, works beautifully.
Note:
Building a payload XML Value,Phase is a great way to load all Ir Code's.
After that Place payload 1 {1} in the command parameter for TCP.Single.Write or TCP.Single.WriteLn then say the phrase and watch the magic.
Excellent work Mr jitterjames.
Future additions:
Somehow listen for received information and display as an event eg: completeir,1:1,1.
Reference for building payload XML: http://www.youtube.com/watch?v=lPyfxpXRr9Q (http://www.youtube.com/watch?v=lPyfxpXRr9Q)
-
Good job. OK I'll talk about the received event tomorrow.
I'm not sure how useful it would be in this situation but it's still a good exercise to see how to do it.
;D
-
Is there a way to have a say a XML of all codes for a device:
Amplifier.xml
Projector.xml
Dvdplayer.xml
Then use them in different commands.
For example:
I know one command can access the XML via 2 phrases as normal with the TCP plugin:
command: Amplifier Controlls
Macro phase "Amplifier"
Payload xml phase "Power On"
= "Amplifier Power On" = Turns amplifier on.
What I'd like is a command that runs multiple payloads from a single phase:
Command: Movies
Macro phase: "Watch DvD"
# part I'm missing
Result: send 'power on' code from Amplifier.xml + ''power on' from Projector.xml + ''power on' from Dvdplayer.xml
I know I can turn multiple things on by putting the actual IR code in the TCP.Single.Write parameter.
But if I have 6 devices and setup multiple combinations for the devices it's too easy to loose track of commands. If I was to change a device it would take forever to update all the codes.
Much easier to use one XML file then a single code change can populate throughout the program.
Any ideas how I can achieve this?
-
Hi Mace,
I'm a bit confused by some of the terminology you are using. You keep using the word "phase". Do you mean "phrase"?
What is a "macro phase", or "macro phrase"?
What I'd like is a command that runs multiple payloads from a single phase:
This doesn't really make much sense to me, in that if it were possible, it would not really be a payload anymore. I think what you want is a way to maintain a dictionary of key-value pairs so that you can, look up the value of a key at any time. There is no direct support for this in VoxCommando at this point. There are of course ways to go about it though. No matter how you do it, you will need to make sure that you key is spelled correctly or it won't work.
One possible method would be to use python. If you do that, pretty much anything is possible. You could create a dictionary of all your codes and then pull out the value of a given key. This value could then be sent to the iTach somehow.
I am thinking about ways to integrate this concept into VoxCommando in the most flexible way possible, so that it can be applied to as many scenarios as possible. It is coming, but it will take some time for me to get around to it, figure out the best way, and actually implement and test it. I already have many tasks of varying complexity that need attention.
-
Yes sorry phrase.
And yes you hit the nail on the head with dictionary, exactly what I was thinking.
Macro I'm thinking of with EG. Need to learn VC terminology more. lol
Naturally to implement this ability is big job, specially to offer maximum versatility and funcunality.
Add it to the list.
In the mean time ill play with Python for the complex stuff and if I have some success ill post up for everyone.
Thanks for the great response.
-
I'm working on something in Python now that should get you started. Stay tuned.
-
Sweet!
Just made my day.
-
Sweet!
Just made my day.
OK, I posted it here:
http://voxcommando.com/forum/index.php?topic=1052.msg8846#msg8846
-
Good morning,
I have a lighting controller that is able to accept telnet commands over port 23 on Ethernet. Here is an excerpt from the published integrations protocol for third party integration:
Single Ethernet Port
IEEER 802.3 Auto-Sensing 10BaseT / 100BaseTX
Supports MDI/MDIX auto-crossover (no crossover cable needed).
F emale 8P8C Computer RJ-45 socket
Green "Connect" LED, Amber "Activity" LED
Use Cat 5 cabling or better
TCP / IP Settings
DHCP (dynamic) or static configuration <factory default = DHCP>
IP Address: <static default = 192.168.1.50 or dynamic configuration>
Subnet Mask: < static default = 255.255.255.0 or dynamic configuration >
Gateway: <static default = 0.0.0.0 or dynamic configuration>
Protocols Used for Integration
TELNET
Telnet Server
Up to 4 telnet sessions can be had simultaneously
Used by software and/or third party equipment (i.e. touch screen)
Limited to transferring ASCII characters
Telnet Port number is 23, can be changed using the software
Login: admin
Password: integration
Notes:
-Only one connection per login / password is allowed at a time.
The system allows for control and monitoring of status of devices such as dimmers, switches, time clocks, keypads etc.
here is a snap shot of an example Device Command structure:
https://www.dropbox.com/s/ldfnddbf6lldnuw/Example%20Device%20Commands.jpg
Please let me know if I understand the capabilties of the TCP plugin.... it seems to me that this could work, but I am not sure.
Appreciate any input whatseover.
thanks.
-
As James will be less available over the next few days, I'll just say that the answer--from what I understand--is that thus far we don't know of anyone who's tried using the TCP plugin to pass telnet data, but that doesn't mean one can't.
Until James has time to look into this himself, one suggestion would be that you install the plugin and try to create some basic commands for your device, since the only cost is time. :)
If you haven't found it yet, here is the documentation on the plugin: http://voxcommando.com/mediawiki/index.php?title=Plugin_TCP
As people here will no doubt confirm, James is generally very open to improving his software, so if you can't get the plugin to work out of the box, he will likely be willing to update the plugin to overcome the problem.
(Full disclosure: I'm his wife and we just had a quick exchange in which he asked me to convey the message, "You can tell him it might work, but if not I'd be willing to try to make it possible.")
-
Thanks! I have to install the system in question to test it so will do so this weekend. It is a scalable system so i can start by simply installing a couple of devices and getting the main brain onto my network set up with a static IP address...
I will let you know by Monday if I have had any success and if so to what degree.
Have a great weekend.
L.
-
Cheers. We look forward to hearing how you fare. If we can help in the interim, let us know.
- N.
-
In case it helps, <cr><lf> would be represented as \x0d\x0a with the TCP plugin
So you could try the TCP.Single.Write action with the message
#DEVICE,4,1,3\x0d\x0a
For "press button 1"
If you want to perform queries, you'll need to use the client actions, not single.
-
Thank you sir...
what thing on my mind before even hooking up to try this is the fact that it (the system processor) will be looking from credentials (username and password) prior to even being in a state to accept my text strings. Would I set up the strings to automatically send username first and password second prior to any voice driven text commands?
On a side note; what would be the best reading/code to learn for me to understand the whole concept/framework of this great piece of software? The possibilities of this application in my mind are endless but I would love for it to not be such a struggle for me to understand.. I have been reading the wikis and watching the videos and see that it is very powerful if one fully understands the mechanics of it.
L.
-
On a side note; what would be the best reading/code to learn for me to understand the whole concept/framework of this great piece of software? The possibilities of this application in my mind are endless but I would love for it to not be such a struggle for me to understand.. I have been reading the wikis and watching the videos and see that it is very powerful if one fully understands the mechanics of it.
Hopefully others can pipe in here too. If you've already watched some demos and the consulted the wiki, I strongly recommend the video tutorial "VoxCommando Tutorial 1A Editing and Building Commands" ().
You could follow-up with the video, "VoxCommando Tutorial 1B more about payloads and the command editor," but I would actually suggest not watching that video until you've really explored VoxCommando yourself, opening up existing commands to try to dissect how they are structured, modifying commands yourself, etc.
This program has *so many* different features and possibilities (in part because it is designed to collaborate with a broad range of 3rd party software and devices). For most new users the best approach is probably "learning by doing," using the wiki documentation, forum, and videos to help resolve questions as you go along.
-
In general, I recommend for new users the following wiki starting points (especially for fairly fluent English readers and those who can handle text longer than a tweet).
Customizing Commands (in terms of understanding the fundamental command concept, which is the backbone of the program) http://voxcommando.com/mediawiki/index.php?title=Customizing_Commands
And for those who are still setting up their system, figuring out microphone issues and language settings etc.:
Getting Started http://voxcommando.com/mediawiki/index.php?title=How_to_use_VoxCommando
FAQ http://voxcommando.com/mediawiki/index.php?title=FAQ
-
Thank you sir...
what thing on my mind before even hooking up to try this is the fact that it (the system processor) will be looking from credentials (username and password) prior to even being in a state to accept my text strings. Would I set up the strings to automatically send username first and password second prior to any voice driven text commands?
I'm away from a real computer until Tuesday so I can't experiment, and in any case I don't have access to a lutron, but if you are correct, and this login procedure is required, then it may be possible using the TCP client approach, where you create a client, connect, and then send credentials. After that the client should be able to hold the connection, so you won't need to log in again, unless the connection is cut for some reason. It might be necessary to use VC.pause to wait between connecting, sending the username and sending the password. It will probably require some trial and error. After Tuesday I can collaborate with you on this.
-
hi again,.
thank you for you valuable input. I will be installing a few switches, dimmers and a keypad today and attempting to communicate to the processor later tonight/tommorrow. I will test the telnet hook up first doing telnet directly to the unit and ensure that i have connection success that way prior to banging my head over VC telenetting so I know that i will not be hacking in vain :biglaugh :bonk
Will track my success and failures and report accordingly.
L.
-
Hello,
I managed to install a small portion of devices, programmed them and got my processor on my network with a static IP address. I have installed the manufacurer's Android application and proved integration and control over the network of the lightng system with their application. I have also installed hyperterminal and telneted commands to the processor and proved that his method works. The processor will not allow concurrent connections by the same user, but allows different users to connect concurrently. I have therefore made separate log in IDs for the Hyper-terminal login and the log in that I am attempting with VOX.
In VOX, I created a custom group for two commands. I have entered a command called "connect" and a command called "living room lights". I have not tried to do anything fancy at this point with voice control of either of these commands and have so far only tried manually executing them. In the connect command, I have entered an action to connect, an action to pause for 2 seconds, an action to send a single line of text for the username, another action to pause for 2 seconds and finally a second write line action to send password.
Under the living room lights command I have entered only one action and that is to send a single line that is a device button press string that i have proved works in hyperterminal.
I have tried many incarnations of the actions such as TCP.Client.Write.Ln, TCP.Client.Write, ,TCP.single.Write, TCP.Single.Write.Ln etc and have alos tried using carriage returns as <CR> and as \x0d and line feeds as both <LF> and \x0a. I have used them together, alone and without them at all.
Here is a link to some screenshots that show my commands tree, the commands actions setup, the history log showing what happens as i manually send the connect and living room commands to the processor. I have also showed the hyperterminal screen showing the construct of my #device command works and shows feed back from the processor that shows two button presses and associated return of device and LED states (the button that i am pressing is programmed with toggle logic in it's native software so one press is lights off, a subsequent press is lights on). THis proves that i have interfaced successfully with the same command that i am trying in VOX.
I cannot get the commands to work in VOX however and I am uncertain if i am even getting past the login in the processor based on my actions under the connect command.
Here is the link to the screenshots mentioned above.
https://www.dropbox.com/sh/xmcz41n99j99d4h/mgB1PY9VKW
do let me know what your thoughts are when you get a chance.
Sincerely,
L.
-
I think you should try using TCP.client.write and terminate each with \x0d\x0a for every action including the username and password. If you are not sure what delay to use, err on the side of a longer pause until you get it working and then try making it shorter.
-
Also you need to use client write for everything. Don't bother with single, because you need to use the client that you previously logged in with.
-
Hi Jitterjames,
I have got it ;D. Following your advice it seems that the missing key to getting my server connection authorized was to enter the carriage return and line feed into the terminator box in the TCP.Client.Connect command per the attached screen shot:
https://www.dropbox.com/s/e8n0n17h022mtix/Telnet%20session%20successful%20connect%20settings.jpg
This then verifies that i can ouput commands to the Lutron Radio Ra2 Main Repeater using the commands published in their integration protocol. The next question is can VOX monitor the feed back from the system and what would i do with same?
thanks for you help!
-
Exciting. Is your living room light command working as well?
-
It is absolutely! When i get home tonight I will write some voice commands to test. I don't think i will be able to add payloads such as 1-10 for brightness or even 0,2.5,5,7.5,10 as i don't see these types of integration commands in the published integration guide; however there are programmable "phantom" buttons in the processor that can be programmed to affect single lights or groups (scenes) of lights that I can program for everything that I am looking to do. IE I could write logic on the processor side that associates a button press to "all lights in living room to 50%" and another for 25% and another for 75% etc. It could also be a single button press for "table lamps to 10%, Ceiling fan off, ceiling light off, wall sconce 50%" and the command could be "TV Lighting Scene" in VOX to activate the text string that pushes the button that does same.
Looking forward to more testing!
L
-
It should be fun to see how you progress. I'm sure once James is back he'll have some thoughts on different ways to creatively/usefully interact with your system, though it sounds like you're making steady progress on your own.
Can I ask, is this the documentation you're using: http://www.lutron.com/TechnicalDocumentLibrary/040249.pdf?
And if so, can you tell us some of the specific devices you're controlling in your set-up? Is it primarily lights, or also blinds? I can imagine that setting up scenes to customize all the relevant lights and venetian blinds for night-time TV viewing, morning and afternoon viewing could be pretty sweet, for example.
-
Yes that is the correct document and yes blinds are available in scenes. With the right setup and equipment you could even start the hot air popcorn maker to turn on as you set the stage for a movie
-
nipped home for lunch and confirm control of the lighting system via voice through VoxWav on my S4 Android phone. ;D
L
-
Good morning,
I have read up some more on the integration commands and can confirm that it is not possible to directly address a dimmer in this system to either tell it to get brighter or dimmer. It is possible to press buttons that have been programmed to send a load (light, shade, appliance etc) or loads (lights, shades or appliances) to a level predetermined in the native software for the system. In this case I have programmed a floor lamp for testing. I have 5 "phantom" keypad buttons in the native software labeled and programmed to do the following:
Lamp off
Lamp 25%
Lamp 50%
Lamp 75%
Lamp 100%
based on the 5 buttons, I have created 5 actions in VOX to press the respective buttons with the following strings:
#device,1,1,3\x0d\x0a
#device,1,2,3\x0d\x0a
#device,1,3,3\x0d\x0a
#device,1,4,3\x0d\x0a
#device,1,5,3\x0d\x0a
Each of the stings above corresponds to each of the buttons programmed in the system for the preprogrammed levels of the floor lamp.
Under the actions I have played with the following:
Non optional Keyword LAMP OFF for #1
Non Optional Keyword LAMP and optional payload list "soft, low, dim" for #2
Non Optional Keyword LAMP and optional payload list "medium, half bright, 50%" for #3
Non Optional keyword LAMP and optional payload list "medium high, 75%" for #4
Non Optional keyword LAMP and optional payload list "full, 100%" for #5
It works like a charm.
The next issue that I would like to tackle is how to query my lighting system and get responses by OSD and TTS from VOX based on feed back from the system IE:
"is the lamp in the living room on?"
"how bright is the lamp in the living room on?"
there are also wireless RF occupancy sensors that can be added to the lighting system that can be queried as to the last command that they have sent. They can be programmed as "occupancy" or "vacancy" where Occupancy turns lights on when you enter a room and turns lights off when you exit (after a timeout) and vacancy never turns the lights on, but always turns the lights off when you exit (after a time out). When you are programming these sensors in the system, you can choose what loads are affected by the "occupied" and "unoccupied" states. I think that it is possible however to extend the logic of these states beyond the lighting system if we can query their status with VOX and have VOX do other things based on the occupancy state such as "turn on a mic and start listening" and turn on a speaker zone for feedback for example.
Looking at the integration paperwork also indicates that VOX would not be limited to the RR2 system, but could also be used with HWQS and HW Illumination (two other whole home lighting systems with more advanced programming capabilities and bells and whistles.)
In order for me to get feed back from the system, I am guessing that i need to somehow configure the web server in the TCP plugin to have it accept data and process it somehow.
Any hints in the right direction is surely appreciated.
Sincerely,
L.
-
Cool, you are a fast learner :clap
I think the best solution to have feedback and also to get a state of a device is using maps. James has record a video which show you how it works. I recommend you to watch the entire video, you'll find what you're looking for from the position 5:00 minutes.
www.youtube.com/watch?v=k-kwIkmPDtI (http://www.youtube.com/watch?v=k-kwIkmPDtI)
I hope this helps
-
Thanks Kalle,
I will watch it again tonight. I watched this video last night and while the feedback questions were not on my mind. It did however enlighten me on how to make some short work of coding in the strings for a system if i make short cuts for all of the integration options in the integration protocol that are simply represented by in integer in order to assemble them in a "drag and drop" style from a menu that I make myself in mapping.
IE if a the integer at position 2 in each text string has the option of 3, 4 or 9 for button press, button release and LED, it would be easier to pick them from the action of what it represents as opposed to remembering and chancing the mistake of the wrong integer for the intended action.
I think I am getting it?
L.
-
Hi all. I am back home so hopefully I can be of some help, unless you have already figured everything out. I arrived home at 3:00 AM though and have crossed a few time-zones so I am a bit dopey still.
Maps are useful for a few things and are a good way to put names on numbers, so using them for device IDs is a good way. I don't see how they could help with feedback though.
Based on the pdf that Nime5ter posted I think there are two possible ways to get feedback, but depending on what kind of setup you have, feedback might not be so useful anyway other than as something to experiment with.
You should be able to query the state of a device. For example: What is the state of LED 1?
?DEVICE,1,101,9\x0d\x0a
You should then see something appear in your history window. It will be an event with the name of your TCP client. the actual message, similar to what would appear on your telnet screen will be stored in the payload of the event. So once the event is assigned to a command, you will be able to access the message as payload 1. i.e. {1}
Another way to monitor any changes to the system without having to actually ask might be with: #MONITORING, Monitoring Type, action Number
So to see when LEDs turn on or off (I am guessing this would be any switch turning on or off) you could use:
#MONITORING,4,1\x0d\x0a
This should also result in events being generated, but without you having to ask each time.
Once you've got events being generated for things you want to monitor we can try to figure out a clever way to use them. Probably you will want to use Results.RegEx and maybe a combination of that with VC.TriggerEvent, or maybe a little python code.
Often the easiest way to share your commands is simply to copy them from the tree editor and then paste them into a "code block". Use the button with a pound (#) sign on it when composing a post.
Maybe tomorrow we can do a hangout, or similar and experiment a bit, if you are available.
-
Thanks JJ,
I was having trouble seeing any useful feed back when trying out the ?Device strings and now see that from your explanation below is that they were indeed buried in the little 'event' icon on the log. Now that I understand that there is something in there that i can use it should be interesting. Simply remembering the last thing that was sent from VOX to the system is only an assumed device state as there are buttons in the real world as well as the actually dimmer or switch that can be activated in the meantime affecting state.
I have night school tonight, tomorrow and Thursday so it will likely be the weekend again before I get a good block of hands on. I will see what else I can manage to squeeze in reading wise in the meantime.
thanks again.
L.
-
@ James
Sorry for missunderstanding in my post - I mean not a real feedback :bonk only the status of a device that is written in a map (postion 10:25 in the video)
-
Ah yes. That makes sense. I probably should have actually looked at which part of the video you were referring to before I posted. :D
-
Based on the pdf that Nime5ter posted I think there are two possible ways to get feedback, but depending on what kind of setup you have, feedback might not be so useful anyway other than as something to experiment with.
You should be able to query the state of a device. For example: What is the state of LED 1?
?DEVICE,1,101,9\x0d\x0a
You should then see something appear in your history window. It will be an event with the name of your TCP client. the actual message, similar to what would appear on your telnet screen will be stored in the payload of the event. So once the event is assigned to a command, you will be able to access the message as payload 1. i.e. {1}
Another way to monitor any changes to the system without having to actually ask might be with: #MONITORING, Monitoring Type, action Number
So to see when LEDs turn on or off (I am guessing this would be any switch turning on or off) you could use:
#MONITORING,4,1\x0d\x0a
This should also result in events being generated, but without you having to ask each time.
Once you've got events being generated for things you want to monitor we can try to figure out a clever way to use them. Probably you will want to use Results.RegEx and maybe a combination of that with VC.TriggerEvent, or maybe a little python code.
Hi James and Kalle,
I have tried sending text strings from VOX in for the device state query (?device,12,82,9\x0d\x0a) for example; but do not get any feedback in the log at all. The same command entered into hyper-terminal nets me the feed back i am after, but not in VOX. I am simply manually sending the command as a TCP.Client.Write (the same way that I have been successful in sending device actions to turn the lights on or off. I have also tried with the monitoring commands. THe commands show as being sent and there is no apparent error showing in the log, but also no event or feedback of any sort. I am wondering if there is more that I may need to set up in VOX to be able to "catch" the feed back. I am very green when it comes to much of the basics on the protocols in use, but I did read somewhere that VOX can take UDP input from other systems and I am not sure that the telnet output from my lighting processor constitutes anything like this and that there needs to be some augmentation of the the TCP plugin perhaps to allow the "two way" communication at this level.
I admire both of your talents and your acrobatics using the VOX program. I have watched almost all of the videos and have been spending a lot of time reading through many of your posts.
I have been hacking my way around for many years and finally decided to get some formal training. I am taking a CompTia A+ course at night currently and will be following that with the CompTIA Networking+ course this next January in order to get the fundamentals of all the networking bits down pat. I would also like to learn some coding concurrent with my other studies on the side. Being that your VOX project is of great interest, I would like to know if either of you could suggest some "beginner" code resources to better help me understand the logic of what you have built. Would you suggest Python and C# as being suitable for someone with little to no coding experience? I have cut and pasted a lot of code over the years without really dissecting it to do things for example in Excel that are more than just formulas (IE entering and modifying VBA code in the editor). Although this as served me well over the years to do a few odds and ends in excel, I have always yearned for the deeper understanding of the code n order to be able to "speak it".
Thanks for your support.
L.
-
Hi L.
As far as feedback goes, I think I will need to look at your system with you in order to make any progress.
My schedule is fairly flexible, so whenever you have time let me know and we can use a screen sharing program to figure it out.
UDP is really a separate thing that does not come into the picture here. It is a different protocol from telnet. Telnet is like a private phone call, while UDP is more like yelling across a crowded room.
I like c# a lot. VoxCommando is programmed in c# and you can create plugins for VC in c#, but for your purposes, I think it makes more sense to start with python. The py plugin lets you take your macros to the next level and will probably be required to process feedback, assuming it is possible. C# is nice if you want to program exclusively for windows, otherwise something like Java makes more sense.
-
Hi J,
I will touch base with you closer to the weekend about a possible collaboration time. What screen sharing program do you use? I have team viewer installed on my PC currently. If there is something else that I would need to download in the meantime, let me know and I will do so.
thank you for your input on the programming. Was the android app VoxWav done in Java?
L.
-
Just TeamViewer is good.
Yes. VoxWav is written in Java, but heavily reliant on the android SDK. Being able to code in Java is only a small part. Purely from a syntax point of view Java and c# are very similar.
-
Ok sounds good.
>>> print ("I will catch up with you later in the week.")
I will catch up with you later in the week.
L.
-
I have read up some more on the integration commands and can confirm that it is not possible to directly address a dimmer in this system to either tell it to get brighter or dimmer...
After reading what the system outputs for monitoring feed back in hyper terminal (the strings returned based on user input to the lighting system), it turns out that it IS possible to send percentage level commands directly to dimmers as opposed to what I have written above. Using a sting that was returned as output, i have input the string in similar format to the #device command as IE: #output,13,1,33%\x0d\x0a as an action in VOX and had it return the light to 33%. 13 is the device ID for the dimmer, 1 is the dimmer button, 33 is the level. Based on this working, I then wrote the same action over again replacing the 33 with {1} and created a range payload of 1,100 along with the phrase "set lamp level" and it will respond to "set lamp level xx" and to to the specified percentage of brightness based on the number from 1 to 100 stated in place of the "xx" following the phrase. This is a BIG DEAL! (for me anyway ::)) This command is NOT published as an option in the manufacturers published commands for this system.
EDITED: On further reading, it is indeed a published command, it was just not in the specific section related to the specific system and was in an earlier part of the manual related to more general system command information... gotta love searching PDFs by keyword!
-
Cool. I'm glad that you figured it out and that you have applied the correct method of using payloads to it.
I was a bit confused after looking at the documentation, as to why you thought that setting the brightness was impossible, but I was waiting to play with the system myself to see what the deal was.
So it sounds like the only thing left that is still stumping you is the feedback from events.
You are off to a great start! ::wiggle
-
Thanks James,
the wheels are turning! The feed back logging AND Monitoring is going to open a lot of other possibilities. For example, they make a PICO control for the lighting system which is a very small RF control that you could clip to your shirt pocket, put in your pocket or purse or mount on a small table top "pedestal". It is a very economical device to give you remote control of lights or whole scenes on the system. Imagine now if you used one such device to send a command to the lighting system, which is monitored by VOX that then tells VOX to either Listen or not Listen. You could simplify a distributed Mic system for whole home control immensely with this method of toggling VOX to listen or not I would think with a manual "push to talk" approach. Working in VoX's soft mute feature could be activated as the VOX listen command is executed as well. This would ensure the commands spoken when loud media is playing are a non issue for the Start Listening command as well as the subsequent commands unitil the PICO control tell VOX to (or your voice command VOX) to stop listening.
Here is a link to a PICO control: http://www.lutron.com/en-US/Products/Pages/Components/PicoWirelessController/Models.aspx
-
Yes the feedback from a device open a door to many other things. I use a "wristmic" (it looks like a watch) together with Eventghost to set Vox in standby or OFF mode with the buttons on it, but can also do this by voice.
http://voxcommando.com/forum/index.php?topic=1153.msg9783#msg9783 (http://voxcommando.com/forum/index.php?topic=1153.msg9783#msg9783)
As next we test the Omate Truesmart http://www.kickstarter.com/projects/omate/omate-truesmart-water-resistant-standalone-smartwa (http://www.kickstarter.com/projects/omate/omate-truesmart-water-resistant-standalone-smartwa) with VoxWav, if this will work you have always your remote by your side ;) (okay, not the cheapest way)
We have also ideas to create a Wireless Mic, that we can wear as watch or such like as a StarTrek communicator.
-
Hi Kalle,
I did see your post about your wrist adaptation of a wifi headset: stellar Idea! After reading your post and a few others linked to the James Lipsit Website where he uses the HAL2000 controller with very expensive Shure microphone set up for whole home control. My idea lies somewhere inbetween wherein you have the permanently installed mics around the house (or at least in the areas of interest of having voice control) but instead of the expense of the intelligent Shure backend equipment and HAL2000, the mic circuits could be toggled on and off with a relay on the lighting system (in this case a Lutron RadioRa2 system) and the VOX could be active listening or ignoring on the same commands that toggle the mic relays. This could be achieved using the small RF pico controls mentioned. The come with a "car visor" kit to add a clip that could be for your pocket or belt, a table top pedestal mount and the option of mounting on a wall with or without a faceplate (with a face plate is appears as any other light switch, but without a faceplate it is easy to remove and replace on the wall so you could "grab" it on your way into a room and replace it on your way out, giving it a "place" when you are looking for it).
There is an out of the box relay solution called a VCRX that integrates wirelessly with the Lutron system that has 6 keypad pushbuttons, 3 CCI inputs and 4 CCO outputs that can be programmed in the Lutron Software. Not perfect for everyone I will admit as Lutron can be expensive in it's own right, but that is the business that I am in. One thing for sure is that the Lutron RF technology if within proper working ranges is one of the most stable and bullet proof systems.
here is a link to the VCRX: http://www.lutron.com/TechnicalDocumentLibrary/Visor%20Controls_369-224a.pdf
you will notice that one of the inputs is labelled as a security input. it is possible to wire one of it's outputs back to this input to achieve something like: Yell for HELP and have VOX activate the output, the output activates security mode and you could have all of the lights in the house flash off and on (including the outside) and send a contact closure the security system.....
-
Hello James and Kalle,
I am stumped on what facility to use to 'catch' and output from my lighting system to have VOX treat as an event.
When I have my telnet client connected to the lightng processor and send valid commands to it via VOX, there is clearly feedback of the subsequent action in the processor being reported in the telnet client coming back from the lighting processor, but I have no idea how to have VOX set to "listen" to this output and base an event on this.
for example, if i send a string using TCP.client.write such as #device,20,2,3\x0d\x0a, i get feed back in my telnet client that affirms the action as "~device,20,2,3". It is this output that i would like to turn into an event to then send a VC.on command.
Any hint in the right way to do this?
L.
-
::hmm, VC listen as default on port 33000 that you can change in the option menu, but I have really no plan if it can help you ::)
English is not my native language and sometimes I misunderstand a question. :bonk
-
Hi Kalle,
does the VC.Listen command keep the port open until it is closed otherwise?
I will try it and see what happens ::zzz
-
the port is always open, so VC listen also on this port when it is in OFF mode
-
Ok I get it... i thought it was a command until i reread your message. i have set it to the telnet port and will try a few things from there.
thanks for your help.
L.
-
I feel like a one armed swimmer this morning...
I have looked through and through and see events being generated in the log such as VC.on or VC.standby, but I not seeing where this is triggered to be an event to show in the log in order for me to endeavor to dissect it and see how this could apply to what I am trying to do.
I have a feeling that somehow i need to have a running xml log that is being generated by the output of my lighting system and the command logic that i need to build the "event" that i am looking for must be based on this xml file and hone in on the string(s) that i am trying to monitor to drive the subsequent action... how to do this? I am also wondering if there is configuration that I need to do with the TCP web-server that is part of the TCP plugin..... I have activated it and see that it is started but when i try to browse to localhost or 127.0.0.1 I just get an error page... Do in need to set up the site under the windows management console somehow as well?
-
To give you a start point with the TCPwebserver, test following:
Start the webserver in the TCP plugin then type in a webbrowser: localhostIP/api/OSD.showText&&hello
if everthing works VC show you a OSD window with "hello"
-
Hi Kalle,
this is what have been trying, I get "this link appears to be broken".
regards,
-
33000 is a UDP port which is not related to this. None of the things you are trying are going to work, but it may break something else, so I suggest you change it back.
You should be getting events generated automatically by the tcp client you have created and connected with. If you are not, then you probably need to adjust your parameters for the connect action. I suspect that your terminator is wrong. Try it with this parameter blank. Then look at what events get generated.
-
Brilliant! = Success! Removing the terminator on my client connection was the key!
El Voxerino you have made my day!
Thanks!
Now I can start my ascent on the mountain of Conditional Logic!
L.
-
I should also mention that this will now make it possible to have the RF Pico hand held control capable of "push to talk" on a single button as it reports one string for being depressed (command = VC.On) and another unique string for being released (command = VC.Standby). You can order these controls with two, three or five buttons, which would theoretically give them up to 10 different actions (5 for each button press and 5 for each button release). This could easily lend it to scrolling through plugin command sets for example to isolate your commands to a particular focus such as lighting, or XBMC or MediaMonkey for example.
-
Please show us some sample payloads attached to your events. It may be that there is still a terminator that we should use, to prevent multiple messages sent together from being combined into a single event.
One way to get the payload easily is with this command (you may need to adjust the event name to match your client name) which will copy the payload to your clipboard. You can then past it into notepad, or directly to the forum in a code block.
<?xml version="1.0" encoding="utf-16"?>
<command id="1120" name="copy payload to clipboard" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="">
<action>
<cmdType>System.SetClipboardText</cmdType>
<cmdString>{1}</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
<event>RR</event>
</command>
-
James,
not even sure I know how to do that. I did however successfully link my button press and button release events since they are being reported to command VC.on and VC.standby respectively (by dragging the events from the log to the command editor per Kalle's excellent YouTube Tutorial on working with events). So on the RF remote I can now push and hold the button, VC.on commands VOX to green, and it stays green until i release the button.
I will look at pasting code per your request later when I have more time on my hands. I am currently wrapped up in another project :(
Thanks,
C.
-
As it turns out this is not working the way I have it currently configured. It seems that any feed back that comes from processor is perceived as the same event, although I can see in the pop up when i roll my mouse over the events that they are unique. The Event Icon they come under however is simply labelled the same name as the group of commands that I have created. What it boils down to is that even though i have dragged the event that I want to correspond to VC.on and the other event that i want to correspond to VC.off to the right locations to fire the approximate actions, any other event that comes in from my lighting processor kicks out an event that is labelled per my group of commands (even though underneath it is different feedback).
I think one quick work around would be to create a different command set just for the on and another just for the off, but it feels like the wrong way to go.
-
Yes. I think it is definitely the wrong way to go.
This is the expected behaviour of the TCP plugin with a client. The event name will always be just the name of the client.
You need to create a single command that can process the events from your unit by analyzing the payload since the event name will always be the same.
-
Good morning,
I have a question that relates to the TCP plugin with respect to clients; can VOX connect to more than one TCP client at a time and keep the sessions concurrently open?
Thanks,
C.
-
Yes. You create a new client using the Tcp.Client.Connect action. Use this multiple times with different client names to create multiple clients.
Note that the server you are connecting to will sometimes only allow a limited number of clients.
-
Thanks JJ,
So if I have more than two or three different processors I am connecting to I can run concurrent connections from a single instance of VOX, which would constitute as one client connection per processor. I have a limitation that I am aware of on my lighting processor that it cannot have more than 4 concurrent users sessions simultaneaously and in no case more than one by the same user log in at the same time. ( IE if i was logging in by an android app and VOX at the same time they would be independent user log ins.)
Thanks,
C.
-
Yes, that sounds right. Provided that by "processors" you mean some kind of TCP server (including devices that allow telnet connections) that VC can connect to. I'm pretty sure that's what you meant, but I just wanted to be clear about it for posterity, since "processors" could mean something else that might confuse some users.
-
Yes, that is what I meant, some type of TCP server including those that allow telnet connections.
-
I have played around with this plugin alot the last couple of days.
Sending both single commands to iTach, Yamaha receiver and trying out tcp.client for feedback from the receiver.
It seems quite unstable to be honest. Sending for example TCP.Single.Write with @MAIN:MUTE=Off\x0D\x0A only works about one of five tries. If I just keep sending the command eventually the receiver will respond to the command.
The same goes for feedback calls with tcp.client. Tried sending @MAIN:VOL=?\x0D\x0A, I got a feedback event every time but most of the time its empty but now and again I receive the payload correctly.
Its just not reliable enough to be useful, at least communicating with my Yamaha A2010. PDF with API for receiver can be found here if interested, http://goo.gl/gJdQAC
For the tcp.client calls I have tried with different delays, after connection is made and before sending command, delay after command, no delay. Doesn't make a difference.
iRule does not have any problem speaking with the receiver, works flawlessly. I also tried telnet to the receiver and sending commands, works without any issues what so ever.
Really need to get this working so I can attenuate the receiver about -40db when voxcommando is activated to be able to send commands reliably.
Just now trying to put receiver in standby using TCP.Single.Write in command editor hitting the "play" button for the command after the fourth try it worked.
Not sure how to proceed, can I active some sort of debug to see where it goes wrong?
In history log everything seems fine, command is sent without any errors.
-
I use the tcp.client actions with my itach and it works 100% of the time. I don't rely on the feedback though since itach basically just says "yeah I got your command and did it". Although I don't use the plugin to control my Onkyo receiver normally because I use the Onkyo plugin, when I did do some tests they worked reliably. I was also able to get feedback from the onkyo but is has been a while since I tested this. Maybe I should try again since the plugin has undergone a few minor updates since then.
I recommend using tcp.client and not tcp.single. I generally leave the client open and do not open and close it for every command.
In order to get feedback reliably using tcp.client you must specify the correct terminator when creating the client.
I recommend you try to use client actions, and if you want to post your command xml I will take a look at it.
If you want you can enable logging in VC and upload your log after trying to send several times. I don't know if it will tell us anything useful or not but it doesn't hurt to try.
I don't really have time to digest the entire protocol as described in that pdf but I did give it a quick look. One thing that caught my eye is this:
2.2.3 Simultaneous Connection (Back To Index)
Maximum Number of Simultaneous TCP Connection: 1
Is it possible that iRule and/or something else is already using that one available connection and thus interfering with VCs ability to communicate with the device?
-
Because of the "Maximum Number of Simultaneous TCP Connection: 1" I would like to close the connection after sending the command so I can use both iRule and voxcommando to control my receiver.
Sending single tcp writes to irule to control my ir lights and so on works every time.
In order to get feedback reliably using tcp.client you must specify the correct terminator when creating the client.
Would that be \x0D\x0A in my case?
Because I have tried that, made no difference.
I also tried client.connect -> client.write -> vc.pause for 10s -> client.disconnect
Made no difference compared to closing the connection directly after sending command using default 10ms delay.
Another thing I noticed is that the feedback event from the receiver is received when closing the connection.
If I add delays like you can see below the feedback event is received first when delays are done and its about to disconnect.
Also after full restart of voxcommando the first command to receiver ALWAYS(even feedback) works.
Quick restart does not guarantee this.
A couple of different logs:
After full restart with a delay of 5s on the command it self.
Two feedback events from receiver as you can see, first one has a payload, second does not.
2013-11-22 09:37:00 27 doCommand:test
2013-11-22 09:37:00 27 action repeat set to: 1
2013-11-22 09:37:00 27 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:37:00 27 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:37:00 27 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:37:00 27 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:37:00 27 [vcevent] TCP.StartListen.test
2013-11-22 09:37:00 27 action repeat set to: 1
2013-11-22 09:37:00 27 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A&&5000
2013-11-22 09:37:00 27 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A&&5000
2013-11-22 09:37:05 32 [vcevent] testEvent
2013-11-22 09:37:05 32 doCommand:testOSD
2013-11-22 09:37:05 32 action repeat set to: 1
2013-11-22 09:37:05 32 Action: OSD.ShowText - Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:37:05 32 [action] OSD.ShowText:Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:37:05 32 action repeat set to: 1
2013-11-22 09:37:05 32 Action: TCP.Client.Disconnect - test
2013-11-22 09:37:05 32 [action] TCP.Client.Disconnect:test
2013-11-22 09:37:05 32 [vcevent] testEvent
2013-11-22 09:37:05 32 doCommand:testOSD
2013-11-22 09:37:05 32 action repeat set to: 1
2013-11-22 09:37:05 32 Action: OSD.ShowText - Payload:
2013-11-22 09:37:05 32 [action] OSD.ShowText:Payload:
2013-11-22 09:37:05 32 [vcevent] TCP.EndListenLoop.test
Same as above but without full restart of voxcommando.
Two events received again but this time both were empty.
2013-11-22 09:43:04 553 doCommand:test
2013-11-22 09:43:04 553 action repeat set to: 1
2013-11-22 09:43:04 553 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:43:04 553 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:43:04 553 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:43:04 553 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:43:04 553 [vcevent] TCP.StartListen.test
2013-11-22 09:43:04 553 action repeat set to: 1
2013-11-22 09:43:04 553 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A&&5000
2013-11-22 09:43:04 553 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A&&5000
2013-11-22 09:43:09 545 [vcevent] testEvent
2013-11-22 09:43:09 545 doCommand:testOSD
2013-11-22 09:43:09 545 action repeat set to: 1
2013-11-22 09:43:09 545 Action: OSD.ShowText - Payload:
2013-11-22 09:43:09 545 [action] OSD.ShowText:Payload:
2013-11-22 09:43:09 545 action repeat set to: 1
2013-11-22 09:43:09 545 Action: TCP.Client.Disconnect - test
2013-11-22 09:43:09 545 [action] TCP.Client.Disconnect:test
2013-11-22 09:43:09 545 focused: VoxCommando
2013-11-22 09:43:09 545 [vcevent] unFocused.chrome
2013-11-22 09:43:09 545 [vcevent] focused.VoxCommando
2013-11-22 09:43:09 545 [vcevent] testEvent
2013-11-22 09:43:09 545 doCommand:testOSD
2013-11-22 09:43:09 545 action repeat set to: 1
2013-11-22 09:43:09 545 Action: OSD.ShowText - Payload:
2013-11-22 09:43:09 545 [action] OSD.ShowText:Payload:
2013-11-22 09:43:09 545 [vcevent] TCP.EndListenLoop.test
Removed all added delays(full restart)
As you can see only one event received and it contains correct payload
2013-11-22 09:45:22 755 doCommand:test
2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:45:22 755 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:45:22 755 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:45:22 755 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:45:22 755 [vcevent] TCP.StartListen.test
2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:45:22 755 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action: TCP.Client.Disconnect - test
2013-11-22 09:45:22 755 [action] TCP.Client.Disconnect:test
2013-11-22 09:45:22 755 [vcevent] testEvent
2013-11-22 09:45:22 755 doCommand:testOSD
2013-11-22 09:45:22 755 action repeat set to: 1
2013-11-22 09:45:22 755 Action: OSD.ShowText - Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:45:22 755 [action] OSD.ShowText:Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:45:22 755 [vcevent] TCP.EndListenLoop.test
Second time without full restart
This time feedback empty
2013-11-22 09:46:40 413 doCommand:test
2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:46:40 413 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:46:40 413 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:46:40 413 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:46:40 413 [vcevent] TCP.StartListen.test
2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:46:40 413 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action: TCP.Client.Disconnect - test
2013-11-22 09:46:40 413 [action] TCP.Client.Disconnect:test
2013-11-22 09:46:40 413 [vcevent] testEvent
2013-11-22 09:46:40 413 doCommand:testOSD
2013-11-22 09:46:40 413 action repeat set to: 1
2013-11-22 09:46:40 413 Action: OSD.ShowText - Payload:
2013-11-22 09:46:40 413 [action] OSD.ShowText:Payload:
2013-11-22 09:46:40 413 [vcevent] TCP.EndListenLoop.test
Here is a log with the use of vc.pause after write instead of built in delay in write action.
sent command twise, first time I got feedback correctly, second time I did not.
Only quick restart this time, quick restart does not guarantee correct result on first try as full restart does, just "luck" I guess.
2013-11-22 09:49:21 874 doCommand:test
2013-11-22 09:49:21 874 action repeat set to: 1
2013-11-22 09:49:21 874 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:49:21 874 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:49:21 874 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:49:21 874 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:49:21 874 [vcevent] TCP.StartListen.test
2013-11-22 09:49:21 874 action repeat set to: 1
2013-11-22 09:49:21 874 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:49:21 874 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:49:21 874 [action] 09:49 VC.Pause: 5000
2013-11-22 09:49:26 896 [vcevent] testEvent
2013-11-22 09:49:26 896 doCommand:testOSD
2013-11-22 09:49:26 896 action repeat set to: 1
2013-11-22 09:49:26 896 Action: TCP.Client.Disconnect - test
2013-11-22 09:49:26 896 [action] TCP.Client.Disconnect:test
2013-11-22 09:49:26 896 action repeat set to: 1
2013-11-22 09:49:26 896 Action: OSD.ShowText - Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:49:26 896 [action] OSD.ShowText:Payload: @MAIN:VOL=-25.5\x0D\x0A
2013-11-22 09:49:26 896 [vcevent] TCP.EndListenLoop.test
2013-11-22 09:49:38 706 doCommand:test
2013-11-22 09:49:38 706 action repeat set to: 1
2013-11-22 09:49:38 706 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:49:38 706 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 09:49:38 706 [plugin] TcpMic: Not using message termination byte!
2013-11-22 09:49:38 706 [plugin] TcpMic: New thread created for client: test
2013-11-22 09:49:38 706 [vcevent] TCP.StartListen.test
2013-11-22 09:49:38 706 action repeat set to: 1
2013-11-22 09:49:38 706 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:49:38 706 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 09:49:38 706 [action] 09:49 VC.Pause: 5000
2013-11-22 09:49:43 744 [vcevent] testEvent
2013-11-22 09:49:43 744 doCommand:testOSD
2013-11-22 09:49:43 744 action repeat set to: 1
2013-11-22 09:49:43 744 Action: TCP.Client.Disconnect - test
2013-11-22 09:49:43 744 [action] TCP.Client.Disconnect:test
2013-11-22 09:49:43 744 action repeat set to: 1
2013-11-22 09:49:43 744 Action: OSD.ShowText - Payload:
2013-11-22 09:49:43 744 [action] OSD.ShowText:Payload:
2013-11-22 09:49:43 744 [vcevent] TCP.EndListenLoop.test
-
Hi Scitz0, are you sure that iRule close the connection to your receiver?
-
I am pretty sure that Irule keeps the connection open.
-
iRule on ipad closed and I can successfully telnet to receiver without any problem now whenever I want so I dont think this is the problem.
-
Close Irule, put the terminator into your connect action and leave the connection open. Remove the pause.
Your logs were all showing actions connecting without specifying the terminator.
-
Ok I added \x0D\x0A to the terminator field and removed the disconnect action
I left the command as @MAIN:VOL=?\x0D\x0A and no delays.
I then ran the command but I dont get any respons, waited five minutes.
According to iRule support forum Yamaha receivers automatically drop the connection after 45s if you dont keep sending keep alive messages.
I cant see any event in history log that it terminates the tcp connection though.
I dont get anything after sending write action that relates to the tcp plugin now checking 10min later.
-
Removed terminate code from connect just for test and got this.
Tried two times, the first time I got two exceptions and second time only the last exception.
2013-11-22 13:46:08 56 doCommand:test
2013-11-22 13:46:08 56 action repeat set to: 1
2013-11-22 13:46:08 56 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 13:46:08 56 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 13:46:08 56 [plugin] TcpMic: TCP.ClientError: System.InvalidOperationException: The stream does not support reading.
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at vcPlugin.tcpClient.listenToServerLoop()
2013-11-22 13:46:08 56 [vcevent] TCP.ClientError.test
2013-11-22 13:46:08 56 [vcevent] TCP.StartListen.test
2013-11-22 13:46:08 56 action repeat set to: 1
2013-11-22 13:46:08 56 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 13:46:08 56 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 13:46:08 56 [plugin] TcpMic: TCP.ClientError: System.IO.IOException: Unable to read data from the transport connection: An established connection was aborted by the software in your host machine. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at vcPlugin.tcpClient.listenToServerLoop()
2013-11-22 13:46:08 56 [vcevent] TCP.ClientError.test
2013-11-22 13:46:08 56 [vcevent] TCP.EndListenLoop.test
2013-11-22 13:46:48 882 doCommand:test
2013-11-22 13:46:48 882 action repeat set to: 1
2013-11-22 13:46:48 882 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 13:46:48 882 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&&&testEvent
2013-11-22 13:46:48 882 [vcevent] TCP.StartListen.test
2013-11-22 13:46:48 882 action repeat set to: 1
2013-11-22 13:46:48 882 Action: Tcp.Client.Write - test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 13:46:48 882 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 13:46:48 882 [plugin] TcpMic: TCP.ClientError: System.IO.IOException: Unable to read data from the transport connection: An established connection was aborted by the software in your host machine. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at vcPlugin.tcpClient.listenToServerLoop()
2013-11-22 13:46:48 882 [vcevent] TCP.ClientError.test
2013-11-22 13:46:48 882 [vcevent] TCP.EndListenLoop.test
-
Please post XML commands and a log of the current setup with terminators, sending a few times. I understand you are having feedback issues but are your commands like set volume working?
Do you have problems sending IR with the itach? I never had any problems with it and I also get feedback from it working perfectly because that is what I use to learn IR codes.
-
I could never figure out how to process feedback event in the same command as the one sending the write so this is how I did it:
Notice that I have now changed and readded terminator to connect and removed it from the write itself.
Sending iTach workes without any issues, though I dont use feedback with iTach.
<command id="570" name="test" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="">
<action>
<cmdType>Tcp.Client.Connect</cmdType>
<cmdString>test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
<action>
<cmdType>Tcp.Client.Write</cmdType>
<cmdString>test&&@MAIN:VOL=?</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
</command>
<command id="571" name="testOSD" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="">
<action>
<cmdType>OSD.ShowText</cmdType>
<cmdString>Payload: {1}</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
<event>testEvent</event>
</command>
-
Hitting execute with a few seconds delay give me client reconnect errors every time but this my be correct as I dont close the connection?
2013-11-22 13:57:29 953 doCommand:test
2013-11-22 13:57:29 953 action repeat set to: 1
2013-11-22 13:57:29 953 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent
2013-11-22 13:57:29 953 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent
2013-11-22 13:57:29 953 [plugin] TcpMic: TCP.ClientError: System.IO.IOException: Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: A blocking operation was interrupted by a call to WSACancelBlockingCall
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at vcPlugin.tcpClient.listenToServerLoop()
2013-11-22 13:57:29 953 [vcevent] TCP.ClientError.test
2013-11-22 13:57:29 953 [vcevent] TCP.StartListen.test
2013-11-22 13:57:29 953 action repeat set to: 1
2013-11-22 13:57:29 953 Action: Tcp.Client.Write - test&&@MAIN:VOL=?
2013-11-22 13:57:29 953 [action] Tcp.Client.Write:test&&@MAIN:VOL=?
-
In the command you just posted you don't appear to be sending the command correctly. You are sending
@MAIN:VOL=?
but shouldn't you be sending
@MAIN:VOL=?\x0D\x0A
When you specify the terminator in the connect action, that is the terminator used to detect the end of an incoming message. It is not used for sending.
Also, if possibly please copy and paste a single command or a single group from the tree. I was not able to copy and paste your xml code into my tree the way you posted it, with two commands, not in a group.
We are still in the diagnostic phase. When we get it sorted out (if) and working we can explore other options, like possibly getting feedback directly in a call to tcp.single actions, where you simply specify the maximum time you want to wait. I was thinking about doing this anyway and it seems like something that would make your life easier. But I'd still like to try to get it working as is, since I won't have time to any updates for a while.
-
I was able to get feedback on all my repetitive executes using this:
I then waited 20min or so and tried again, first I received and exception och the first couple of tries, then I got the feedback RESTRICTED, after this hitting execute return the correct feedback every time. So i tried again, waited a couple of minutes or so and again got exception on first couple of tries and then I got the correct feedback. Maybe the receiver force close the connection but the TCP plugin still tries to keep it open and then it takes a while for it to reestablish the connection correctly?
Made a third test and waited about 3m after last successful feedback and this time I was able to continue without any issues, strange.
<commandGroup open="True" name="Yamaha (Test)" enabled="True" prefix="" priority="0" requiredProcess="" description="">
<command id="581" name="test" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="">
<action>
<cmdType>Tcp.Client.Connect</cmdType>
<cmdString>test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
<action>
<cmdType>Tcp.Client.Write</cmdType>
<cmdString>test&&@MAIN:VOL=?\x0D\x0A</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
</command>
<command id="575" name="testOSD" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="">
<action>
<cmdType>OSD.ShowText</cmdType>
<cmdString>Payload: {1}</cmdString>
<cmdRepeat>1</cmdRepeat>
</action>
<event>testEvent</event>
</command>
</commandGroup>
Though I get an exception on repeated executions for client.connect
2013-11-22 14:47:05 889 doCommand:test
2013-11-22 14:47:05 889 action repeat set to: 1
2013-11-22 14:47:05 889 Action: Tcp.Client.Connect - test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent
2013-11-22 14:47:05 889 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent
Exceptions I receive sometimes(different it seems):
[code]2013-11-22 15:35:28 632 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent
2013-11-22 15:35:28 632 [plugin] TcpMic: TCP.ClientError: System.InvalidOperationException: The stream does not support reading.2013-11-22 15:36:35 712 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 15:36:35 712 [plugin] TcpMic: TCP.ClientError: System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at vcPlugin.tcpClient.listenToServerLoop()2013-11-22 15:35:28 632 [action] Tcp.Client.Write:test&&@MAIN:VOL=?\x0D\x0A
2013-11-22 15:35:28 632 [plugin] TcpMic: TCP.ClientError: System.IO.IOException: Unable to read data from the transport connection: An established connection was aborted by the software in your host machine. ---> System.Net.Sockets.SocketException: An established connection was aborted by the software in your host machine
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at vcPlugin.tcpClient.listenToServerLoop()2013-11-22 15:33:11 164 [action] Tcp.Client.Connect:test&&192.168.0.4&&50000&&\x0D\x0A&&testEvent
2013-11-22 15:33:11 164 [plugin] TcpMic: TCP.ClientError: System.IO.IOException: Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall. ---> System.Net.Sockets.SocketException: A blocking operation was interrupted by a call to WSACancelBlockingCall
at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
--- End of inner exception stack trace ---
at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
at vcPlugin.tcpClient.listenToServerLoop()
The thing you mentioned about possibly getting feedback directly in a call to tcp.single actions sounds nice, hopefully you will get some spare time not to far in the future.[/code]
-
Calling connect when you are already connected it may throw an exception but I don't think it matters. You could try putting a TCP.Client.Disconnect before each TCP.Client.Connect but this is not very elegant. It might work...
Yes the receiver will disconnect and the TCP libraries in .Net are terrible about not noticing that the connection has been closed by the remote server. It can take a really long time to notice and may not even notice unless you are sending commands, even when sending command it will put them on a stack or in a buffer or something and act like everything is peachy and still take a while to start throwing errors! Perhaps when we move to .Net 4 there will be something better we can use. With my iTach I can open a connection and it stays open reliably unless the network is unplugged or my computer goes to sleep. When the computer wakes up I do a little thing to reinitialize the connection.
But now that you've got your commands and your terminator done correctly for both sending and receiving you can try the following.
First of all, for just sending commands that don't require feedback, I suggest using TCP.single. I suspect that this will work reliably, and it is a lot less work for VC, but it might not work all the time if iRule is on and actively trying to keep the connection open.
For commands that require feedback (for now anyway) you have a few options.
Option A.
1 - Create a client using TCP.Client.Connect, send the command(s), don't do anything else in this command
2 - when the feedback event is fired process the feedback from the event payload, and then disconnect the client.
This should all happen almost instantly unless your receiver is very slow to respond for some reason. The only problem here is that if the event does not come back from some reason the client will remain connected, or at least think that it is... But you can try it and see if it is reliable now that you are using the terminator correctly.
Option B.
1 - Create a client using TCP.Client.Connect, send the command(s), and then trigger an event by using VC.SetEventTimer. Use any eventName you want but assign that event to a command that disconnects from the client. Experiment to see how long the amp takes to trigger the other event and then try to set the shortest timer delay that will safely let the receiver respond in time.
2 - the feedback event will fire as above but you don't disconnect the client here
3 - the disconnect event will fire next and you can disconnect the client in the command that is triggered.
This should probably work reliably (as long as irule doesn't interfere) but be careful if you have multiple commands going simultaneously that they don't overrun each other where one tries to connect before the other closes (well maybe it will still work...)
Option C. is basically what you were doing before but with the connect terminators and a few minor adjustments.
1 - open the client, send the commands, pause (only for a short time), then disconnect.
This might not work because VC.Pause blocks the main thread of VC and may prevent the TCP stuff from executing. Try it and if it doesn't work change the name of the command so that it starts with ++ This is a trick to run the command in it's own thread. Each of the actions in the command will actually be executed on the main thread, but not the containing macro or the VC.Pause actions. Other actions will be "invoked" or "injected" into the main thread... blech... threading... Anyway, it can be very helpful sometimes but only use the ++ trick when you need it!
Finally, if it turns out that all this works well but only when iRule is NOT running, and iRule starts to interfere then you have to find another solution and you can't blame the problem on VC. If your VC machine is on all the time, then you could probably set it up to relay command from iRule to the receiver without toooooo much trouble ;)
-
I edited my last post a few times so don't just read the version that you got in your email notification... read the forum version.
-
I was able to get feedback on all my repetitive executes using this:
I then waited 20min or so and tried again, first I received and exception och the first couple of tries, then I got the feedback RESTRICTED...
Sounds like the receiver is telling you that, so you'll want to read up on what that means.
-
Ok thanks, I will give your different options a try and report back.
Thanks for all the help so far.
-
You're welcome. :D
-
Hello, good evening.
Excuse my English translation, for I am from Brazil.
I am unable to use the TCP IP plugin.
I need to send an IP address for a server on the LAN, however, in any way I can configure the plugin to control information, ie the IP address has the control information at the end of the address, as being in the following way:
192.168.0.1/t6
Would you like an example of how to configure this IP address in the TCP plugin.
Recalling that need only send this address on the local network as the example above formatted.
Grateful
-
Good evening, Márlon, and welcome to the VoxCommando forum. :)
Please feel free to post your questions in Portuguese. We can use automatic translation tools like Google Translate to translate your questions. But there are also several Portuguese-speaking users who may be able to help you in your native language. This is one reason we invite everyone to post in their own language.
I am not sure I understand your question, but I think you are asking for something like this:
<?xml version="1.0" encoding="utf-16"?>
<!--VoxCommando 2.1.4.2-->
<command id="590" name="change server address to {1}" enabled="true" alwaysOn="False" confirm="False" requiredConfidence="0" loop="False" loopDelay="0" loopMax="0" description="{1} is a "payload". It will be replaced with the payload that you say in your voice command: "t6" or "t5" or "t4".">
<action>
<cmdType>TCP.Single.Write</cmdType>
<params>
<param>your message</param>
<param>192.168.0.1/{1}</param>
<param>8080</param>
</params>
<cmdRepeat>1</cmdRepeat>
</action>
<phrase>change IP address to</phrase>
<payloadList>t6,t5,t4</payloadList>
</command>
If you don't know how to use this example in your command tree, please watch this video: http://www.screencast.com/t/0SOZw4TEvq9
-
I don't think you actually want to use TCP plugin to send messages. TCP servers do not normally accept any extra information in the address. So 192.168.0.1/xxx does not make any sense for a TCP message.
It sounds like you want to send a message using "restful" HTTP messages, similar to typing an address into the address bar on your web browser. If that is the case then you want to use the actions that start with "Scrape" such as "Scrape.Get"
http://voxcommando.com/mediawiki/index.php?title=Actions#Scrape
Maybe you can tell us more about the server that you are trying to communicate with so that we can give you better advice.
Feel free respond in Portuguese. :)
-
I currently have openhab sending a message via http to eventghost whenever my front door opens then use the broadcaster plugin to send an event to VC.......
I'd like to eliminate that middle man. Unless there is a better way to communicate between openhab and VC I'm assuming using the http api would be easiest. What is the correct format to trigger an incoming event via the API?
-
Did you look in the wiki for information on the API?
Actually UDP is easier if that is an option for you.
UDP, TCP, HTTP, Commandline...
All are pretty easy. They all use the same format for messages.
-
I am running 2.2.0.7 of VC as soon I enabled the TCP Plugin with no problem when I installed, I then restarted VC and now whenever I enable the plugin I get this error. http://pastebin.com/hww0Mmq5 Anyone know of a fix or if its fixable?
-
Try rebooting.
If that doesn't help please post a VoxCommando log.
-
I've rebooted multiple times since this first happened, here is the full VC log. http://pastebin.com/8CBi8FEn Seems like there is an error with the webserver.
-
The relevant error seems to be the following:
An attempt was made to access a socket in a way forbidden by its access permissions
Based on this, my guess is that you are having problems starting up the web server and that there is something wrong either with your system or with your setup. Ideally the TCP plugin should handle this error more gracefully. While it may not be able to start the simple web server, it should still be able to handle the exception and load the plugin, so I will have a look at that.
There are a few reasons I can think of why you would get this error. I will start with the most likely causes / fixes and work my way down.
#1 - Firewall or antivirus is blocking you. More likely the firewall. Normally you are asked to create a firewall exception when you start VoxCommando, but to be sure you can temporarily disable your firewall to see if it is a factor. Antivirus... I'm not sure if this is as likely, but you might as well disable it too to test.
#2 - The port specified for the web server is already being used by a program or service on your system. Try changing to a different port. The plugin won't load due to the error which means you can't access the plugin settings at the moment. To resolve this you can either delete file "Options.xml" in the plugin\TCP folder and then restart voxCommando. This will reset the settings and then you can use the UI to adjust the plugin settings. Or you can edit this file by hand and change the line that reads: <Option name="webServerPort" value="8095" />
The reason #2 is not at the top of the list is because I would expect a slightly different error message in the case of a port that is already being used, but you never know.
#3 - Less likely, but easy enough to check. Normally you should not need any special permissions to open a socket, but you can try to disable UAC and/or run VC as administrator to see if it makes a difference.
#4 - You've got some other corruption in your system dlls. I think this is quite unlikely but again, with computers you never know.
#5 - You only have .Net 4.6 installed and it is not 100% backwards compatible. You could try to install .Net 4.1 and/or .Net 3.5 but again this is quite unlikely.
I would start with #2 and just set the port to something you are sure is not being used, then try #1.
Good luck.
-
Update: I just tried a test where I set the TCP simple web server port to 80 and I immediately got the exact same error so I suggest you try another port and that will most likely solve your problem.
-
Deleting the Options.xml worked! Thanks a lot! Although I figured out how to control VC with Tasker using UDP.
-
To give you a start point with the TCPwebserver, test following:
Start the webserver in the TCP plugin then type in a webbrowser: localhostIP/api/OSD.showText&hello
if everthing works VC show you a OSD window with "hello"
Hello Kalle
Is it possible that the "adress" must be localhostIP/api/OSD.showText&&hello
Than the event is happend
I'm using VC 2.2.0.7
greetings fishware
-
Yes, that was probably just a typo, and the post is also from several years ago.
Hopefully most users will consult the official documentation on the wiki when forum post suggestions don't work as expected.
The wiki specifies that two ampersands (&&) are required between parameters:
http://voxcommando.com/mediawiki/index.php?title=API_Application_Programming_Interface#TCP
-
Sorry for the confusion - I have now corrected the old posting :bonk