Serial Device question

[incoronado]

This is more of a general question on how users have set up serial devices. I have a Yamaha RX-V2600 that I use HB to control. There are really two components that relate to the RS-232 communication. There is monitoring status component, and control component. Do I have to set up two separate sets of properties? One that relates to control and one that relate to monitoring status. How are you all handling this? It seems to make a lot of sense that one set of objects handles both scenarios. For instance, I have a slider that allows me to CONTROL volume via HB. If I change the volume using a remote control, I want the slider to reflect that new volume setting. I currently have a complicated, too complicated, process that makes use of tasks, and modes to accomplish this without getting into loops. Any ideas on this would be appreciated. It would be nice if HB 3.0 would allow the same objects to be used for status and control with the ability to turn off the sending of a serial command if it was the result of receiving a status command. It would also be nice if you could link received serial commands, or multiple commands, directly to a value without the use of tasks or scripts. Just seems like a logical progression of a good concept. That would be extremely useful and very efficient.

[Richard Naninck]

If you set up a serial device, you get a received data property which reflects all of your received data alias status from the yamaha. Does the yamaha put data on the serial port when it is controlled using the IR remote and/or the controls on the machine itself? If so, you can keep a perfect status like I can with my Onkyo receiver.
You can setup lots of properties with property labels that reflect all of the functions the yamaha has OR you just use 1 extra property and name it "*". Bind this property to the hardware devices single label %1% or %x% depending if it is plain ascii or hex and a script will do the rest.
If you check the scripts section, you will find a script I uploaded for use with an Onkyo. It handles both status and control. It is a continuous running script and triggers either on a change in the received data property or an action property. Received data is parsed so that all commands are taken care of and the action property can contain just about everything you like it to be.

[incoronado]

Yes. The Yamaha works in a very similar way and sends a serial report command when the receiver is changed via remote, front panel, or as the result internal system change. How do you stop the receive data from triggering another send when it changes the property value. in other words, you have a property with a value of Power State that takes a value of On or Off. You have tied that value to a serial command that you have configured in the serial device. You have a button that you have tied to that property. You have also configured a script that will take serial data. If HB receives a serial command to turn Power Off ( via the remote) Based upon receipt of this serial command you change the value of the property Power State to Off. That process will send the serial command to the receiver. This will, in turn, cause the receiver to generate another serial message to be sent to HB received data property.

[Richard Naninck]

The way you describe above is the way it is intended I guess and it is also the way I used when I first started out with HB. However it asks for lots of configuration and scatters lots of settings over many properties, devices and tasks.

For status you need a script. For control you can use properties bound to commands in your hardware device. You can trigger your status script by using a task that listens to the received data property and triggers the script when this property changes. I used to do it this way, but a while back HB had a memory leak when starting scripts. So turning the volume knob would rapidly increase memory usage because the script triggers at every serial command hence memory was lost.

To overcome the above I created a continuous running script and found this to be much more flexible. Later this memory leak was fixed, but I remained my running scripts. Then I found out about the wildcard serial property that can be used to send just any command through the serial device by using just one hardware property label "*". After figuring out how that worked I deleted all my hardware serial commands and got rid of all the bindings to the control properties and tied everything up in the same script.

A script is built in the following way:

Create a Do Loop with a sleep 1 so cpu usage stays at 0%. Read the received data property and test it against the previous one. When changed, parse the data and jump through a select case to the respective received command sub. These subs store data in the NULL device alpha numeric properties which can be used to display status in your swremote, trigger tasks or whatever you like to use them. You can choose your own labels ie: Create a NULL Device Power property and the Power Sub puts in On or Off. When more serial commands are received in the same message, loop through the amount of commands so none are missed.
As for the sending part I do the following: In the same Do Loop also read the status of a NULL device Action (alpha numeric) property. When a SWRemote button, task or whatever puts something in this action property, the Action changes from "Waiting" to some command (just like my music script) and you jump again to the select case handling all of the Action Commands. So lets say you want to switch the Power to On with a swremote button. Select the NULL device for this button, select the Action property and put the command Power^On. The ^ is a separator. Now the script is triggered because Action changed from Waiting to Power^On. Jump to the SendData sub and Split the command from the data. Command is Power and Data is On. If the Command is Power, jump to the Power Sub with Data in the Call. Now in the Power Sub, you send the Data through the wildcard by doing: SetPropertyValue "Yamaha.Send Data", "Power On". The Send Data Property is bound to the wildcard * in the hardware device. This way you can send any command without having to pre-define it first and all is tied up in one script.

Now for your question.
You send Power On. The script handles this and the Action property falls back to Waiting. The receiver gets the command, switches on and sends the Power On status. The Received Data Property receives the command for Power On and the Status part of the script gets triggered because the OldReceived Data differs from the Received Data. Parse the data, jump to the correct sub and fill the power status property and all stops there. There should be no recurrencies whatsoever because Received Data doesn't trigger Send Data unless you program it that way.

Obviously this is just one way of doing it, but it kept my system very clean since I use many serial devices. HB is just a layer for serial control with an occaisional task and a very nice SWRemote. All the rest is done through scripting.

Hope this helps.

[Richard Naninck]

@Incoronado

How are you going with this?

[incoronado]

Sorry. I took your advice and ran with it. As usual. Using a looping script instead of using tasks to trigger scripts seems to be the best way to go.