TCP Plugin

[Crunchie]

nipped home for lunch and confirm control of the lighting system via voice through VoxWav on my S4 Android phone.

L

[Crunchie]

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.

[Kalle]

Cool, you are a fast learner 

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

I hope this helps

[Crunchie]

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.

[jitterjames]

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?

Code: [Select]

?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:

Code: [Select]

#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.

[Crunchie]

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.

[Kalle]

@ James

Sorry for missunderstanding in my post - I mean not a real feedback  only the status of a device that is written in a map (postion 10:25 in the video)

[jitterjames]

Ah yes.  That makes sense.  I probably should have actually looked at which part of the video you were referring to before I posted. 

[Crunchie]

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?

Code: [Select]

?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:

Code: [Select]

#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.

[jitterjames]

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.

[Crunchie]

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.

[jitterjames]

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.

[Crunchie]

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.

[Crunchie]

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!

[jitterjames]

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!