Serial control mapping

[jasonb1]

I'm setting up for serial control of a Pioneer Elite receiver. It turns out that the %1% syntax for inserting a property value in the serial hardware interface isn't going to work for this one because the values always should be zero prefixed to a certain length. The volume is always two characters, i.e., 01, 02, 03, 50, 93, etc. Not 1, 2, 3, 50, 93, etc. Can we get a feature to specify the number of digits for zero padding for numeric properties?



The other commands like "set function" (radio, dvd, vcr, etc.) and "listening mode" all work like volume in that they want zero padded numbers for the function/mode to a certain size. (2 and 4 in these cases) Since there are fewer functions and listening modes than volume, those call all be entered one at a time as a separate command of course.



- Jason



P.S. Since there are a lot of listening modes, I was thinking it would be nice to have a feature where you could have a mapping table from property value to numeric value for including in a serial command, but in the end figured it wasn't really necessary. Perhaps it would make things easier for others with certain classes of more dynamic devices, but I couldn't think of any...

[ScottBot]

Jason,



I admit that that Generic Serial Control Device/Interface Plugins are very basic. My hope is that any additional data processing that needs to be done beyond what the Generic Serial Plugins can do, could be provided using a Script.



Here's what I would suggest:

1. Add a User Definable Numeric Property to the receiver Device. Something like Padded Volume.
2. Create a Script Device for the "Volume Fixup".
3. Have the VB Script simply take the receiver Volume Property and determine whether it needs padded (< 9). Have it set the new Padded Volume Property with the new padded (or not padded) value.
4. Create a Task to execute the script. Set it as "When Conditions Are Met".
5. Give it a condition that uses the volume value of the Device that will ALWAYS evaluate as True (for example, if Device.Volume Does Not Equal -1).
6. Add a single Condition to the Task that sets the script device State = Running.
7. When mapping the Serial Commands to Property Values, use the new Padded Volume instead of the old volume Property. You will still need to use the %1%, but the values will now be padded.

Scott

[jasonb1]

I can't seem to get that to work because:

1. If "Padded Volume" is numeric then the padding gets lost by the time the property is set.

2. If I make it Alpha, then I have to input all 100 values as discrete values because otherwise I can't assign a command.



It's unfortunate that you can't optionally assign a command to the entire property itself instead of property+value.



Also, it looks like I have to keep the actual Volume property elsewhere like on a null device because it would fail to set because there is no command mapping.



Am I making sense or am I just dense?

- Jason

[jasonb1]

I got it to work by doing the additional things that I mentioned:

1. The real volume is kept in a null device.

2. The padded volume is an alpha property with each value enumerated.



Since this is no different than the way input and listening mode selections work in the command set of this device, they have been implemented the same way.



Since there are 94 volume levels, 63 listening modes, and 12 input selections, that was a lot of typing in the property manager dialog and the modes/input scripts.



Thanks.

- Jason

[ScottBot]

Jason,



Glad to hear you got it working, sorry to hear it was such a pain.



For the IR Device mapping I had added a special case where you could specify '*' as a Property value and map that to an IR Command (the same way the generic commands are mapped). If the Property Value changes and it does not find the command, but it does find the '*', it sends it to the interface anyway. This allows you to use the %1% by mapping an IR command to a Property by way of the "*" value.



Unfortunately, I've never made the same modification for the Generic Serial Device.



Scott

[jasonb1]

I think adding the "*" mapping for serial would go a long way to solving these issues and it's probably pretty easy, right?



For example, I just discovered that the channel number command for RCA style DSS wants the channel number as two byte hex, and to implement that with my previous scheme would require an hour of typing...



- Jason

[ScottBot]

I think it should be fairly easy to implement. I'll look into it and let you know.



Regardless of how easy, it really should be that way.



Scott

[ScottBot]

Jason,



It seemed easy enough. Here's what you need to do:

1. Download the Plugin from here.
2. Stop HouseBot.
3. Unzip it and copy it into your \HouseBot\Plugins\Interfaces directory. You may want to backup the existing file first.
4. Run HouseBot.

I think at this point you are probably more familiar with the Property Manager than I am, but here's a rough sketch of what you need to do.

• Create a new Property in the Property manage for your Volume (or whatever).
• Give it a single value of *.
• Add that new Property to your Generic Serial Port Device definition. Or you can probably just right-mouse-click on your existing Device and add it that way. If you add it to the device definition, you will need to create a new device.
• Associate the * to your volume Serial Command.

Let me know how this works for you.



Scott

[jasonb1]

Works like a charm.



I haven't actually hooked up my devices to the COM ports yet, but according to the logging I turned on, the right byte values would be dumped out to the serial port. Thanks very much!

- Jason

[jasonb1]

It works great in the non-hex scenario. I converted my previous efforts to the new method and that works fine.



The snag that I'm running into now is that when it inserts property value to the output it converts the ASCII into hex equivalent per character. I think there needs to be a way to specify that it should take the ASCII in the property value and "interpret" it as hex before sending out just like the the hex mode in the serial definition setup does.



- Jason

[ScottBot]

Jason,



First, I think I told you the wrong directory to put the Plugin. It goes into the Devices directory, not the Interfaces directory. I guess you figured that out.



Are you saying that you want it to do the %1% substitution first. And then convert entire result to hex? It's probably more logical to do it this way, instead of having a mixed hex/ascii stream.



Scott

[jasonb1]

That sound good to me.

[ScottBot]

Jason,



One problem I'm having with this is dealing with exactly how to translate the ASCII to hex. For the Command strings it's easy; they are entered as two digit pairs representing their hex value. However, for the substitution values, there can be different ways to convert the data.



For example, I assume that you need to convert the full numeric value straight into hex. So if your volume level is 100, it needs to go out as "64". However, if I were to convert the 100 as ASCII, it would go out as "01 01 00".



Maybe I can use a %a% for ASCII conversion, and use the %1% for numeric conversion. Any ideas on if this would work for you?



Scott

[jasonb1]

Since the hex output for various devices could be complicated and there isn't a rich format string to specify the number of hex digits to output, I figured that I would use a script to populate a property with the actual hex bytes that I wanted to output. My command string in the serial definition for the channel change command is FA46%1%. So, to set channel 900, I would have a script set the value of a alpha property to 0384. Channel 9, I would set the value of this property to 0009.



So, I'm hoping the final output in hex would be FA 46 03 84 or FA 46 00 09, but what I'm getting now is FA 46 30 33 38 34 or FA 46 30 30 30 39.



So, if you add a %a% that would accomplish the proper conversion, that would be terrific.



- Jason

[ScottBot]

Jason,



I've got a new version of the Hardware Interface for you to try. If you use the old %1% it will treat the data as ASCII and do a straight transfer into the buffer. This is the same; I didn't want to break any existing configurations. If you use %d%, it will tread the data as numeric and transfer it into the buffer with a number conversion.



Give this new plugin a try and let me know how it works for you.



Like before, unzip it and copy it into your Plugins\Interfaces (this one REALLY goes into the Interfaces directory).



Scott