I have a few simple questions about the generic serial plugin.
I have a device which expects numeric values to be 0 padded to a specifc number of places. e.g. to set the volume to level 14 I'd say '014MVLZ'. Perhaps allowing FormatMessage or sprintf style formatting? '%03d%MVLZ'
This same device can give me a binary dump of its status whenever it changes. I imagine parsing this is beyond the generic serial interface device capabilities. Now, to make sure I'm getting the general idea of how this all works, I'd write a Device, not Hardware, plug-in and have it talk to the existing serial hardware plug-in..?
Judging from the sample 'System Time' device, I'm assuming that once I do that it would be a simple matter for the UI to reflect these status properties.
generic serial plugin
Paul,
As you are discovering, the Generic Serial plugins work well for a wide range of simple ASCII protocol command devices. Although the plugin has been extended many times to include more and more flexibility, at some point it makes more sense to just write a specialized plugin for the hardware.
You would definitely need to write a Hardware Interface plugin. This would replace the functionality of the generic serial Hardware Interface. Typically if you write the Hardware Interface plugin, it makes sense to then write your own Device plugin as well. This allows you to customize your Device Properties and behaviors however you wish.
Once you create your Device, it's Properties and values will operate within the system as any other Device Properties.
As you are discovering, the Generic Serial plugins work well for a wide range of simple ASCII protocol command devices. Although the plugin has been extended many times to include more and more flexibility, at some point it makes more sense to just write a specialized plugin for the hardware.
You would definitely need to write a Hardware Interface plugin. This would replace the functionality of the generic serial Hardware Interface. Typically if you write the Hardware Interface plugin, it makes sense to then write your own Device plugin as well. This allows you to customize your Device Properties and behaviors however you wish.
Once you create your Device, it's Properties and values will operate within the system as any other Device Properties.
Scott
-
Paul Forgey
- Member
- Posts: 42
- Joined: Thu Mar 18, 2004 9:51 am
-
Richard Naninck
- HouseBot Guru Extraordinaire
- Posts: 1121
- Joined: Tue Sep 28, 2004 7:49 am
- Location: The Netherlands
Howto write your own hardware device plugin?
Scott,
I also control my Onkyo receiver via your generic serial device. Output works fine, but feedback from the receiver is really difficult to manage with the current generic serial device driver.
Do you have sample code of the generic serial device orso that I can use to write a dedicated Onkyo serial plugin for my receiver. By doing that, I could parse all of the feedback like it is supposed to be and have an alive status of my receiver all the time. Furthermore, I guess the response times could also be tweaked a bit.
It would be nice if in time a complete plugin database would develop for all kinds of serial devices like audio equipment and so on. All top level amps and receiver carry a serial out these days.
Thanks,
Richard
I also control my Onkyo receiver via your generic serial device. Output works fine, but feedback from the receiver is really difficult to manage with the current generic serial device driver.
Do you have sample code of the generic serial device orso that I can use to write a dedicated Onkyo serial plugin for my receiver. By doing that, I could parse all of the feedback like it is supposed to be and have an alive status of my receiver all the time. Furthermore, I guess the response times could also be tweaked a bit.
It would be nice if in time a complete plugin database would develop for all kinds of serial devices like audio equipment and so on. All top level amps and receiver carry a serial out these days.
Thanks,
Richard
-
Paul Forgey
- Member
- Posts: 42
- Joined: Thu Mar 18, 2004 9:51 am
Richard: I think my code could really help you once I get it actually complete enough.
meedio people: Are there any legal problems making my code available for my Krell plug-in in general? Just to board members? To anybody?
It's also derived from the template projects, so there's a bit of the template code sprinkled throughout it. Even without that, I know some software manufacturers are strict about keeping plug-ins proprietary.
meedio people: Are there any legal problems making my code available for my Krell plug-in in general? Just to board members? To anybody?
It's also derived from the template projects, so there's a bit of the template code sprinkled throughout it. Even without that, I know some software manufacturers are strict about keeping plug-ins proprietary.
-
dlmorgan999
- HouseBot Special Member
- Posts: 409
- Joined: Tue Jul 13, 2004 9:13 am
- Location: Tigard, OR
Paul,
If the serial protocol is published, I don't think there would be any issues with sharing your code. Any code you use from the HouseBot SDK can also be used and shared in any way.
Richard,
If it's just the received data that you are trying to parse, another option that you may want to consider is to write a VB Script to parse the received data. The script could then update various Property Values.
If the serial protocol is published, I don't think there would be any issues with sharing your code. Any code you use from the HouseBot SDK can also be used and shared in any way.
Richard,
If it's just the received data that you are trying to parse, another option that you may want to consider is to write a VB Script to parse the received data. The script could then update various Property Values.
Scott
Scott,
This thread brings up a good point. The samples that are in the SDK are a good starting point, but it would be nice to have a more indept 'sample' included also. Would it be possible to see the code for one of the current hardware/device interfaces? This way we could see how each piece of code is reflected in the HB GUI and such.
I know you will say that it is hard to do because people don't have the same set-up, but I would think that just being able to see the guts of a real life plugin would take us a lot further into the plugin development world.
This thread brings up a good point. The samples that are in the SDK are a good starting point, but it would be nice to have a more indept 'sample' included also. Would it be possible to see the code for one of the current hardware/device interfaces? This way we could see how each piece of code is reflected in the HB GUI and such.
I know you will say that it is hard to do because people don't have the same set-up, but I would think that just being able to see the guts of a real life plugin would take us a lot further into the plugin development world.
Thanks,
Scott J
aka spike5884
Scott J
aka spike5884
-
dlmorgan999
- HouseBot Special Member
- Posts: 409
- Joined: Tue Jul 13, 2004 9:13 am
- Location: Tigard, OR
-
wallebalboa
- Senior Member
- Posts: 111
- Joined: Wed Aug 11, 2004 6:52 pm
- Location: Sweden
code for serialcontrol of DSP
Hello.
I am planning to write a serial control for a Rotel DSP. As a rookie on C i need as much help as possible.
How are you two progressing with your code? Are you willing to share?
Is the source to the meridian plugin available to use as a sceleton? (who wrote it, Scott?)
The major reason for not using the generic serial is that the DSP is reporting status on the serial port every time it changes, even if the change is not initiated from the serialport. I also want to add a "absolute volume property" not only up/down.
regs
I am planning to write a serial control for a Rotel DSP. As a rookie on C i need as much help as possible.
How are you two progressing with your code? Are you willing to share?Is the source to the meridian plugin available to use as a sceleton? (who wrote it, Scott?)
The major reason for not using the generic serial is that the DSP is reporting status on the serial port every time it changes, even if the change is not initiated from the serialport. I also want to add a "absolute volume property" not only up/down.
regs
Yes, I wrote the Meridian plugin. It's a very simple plugin and could probably have been implemented with the Generic Serial plugin (but the Generic Serial plugin was developed after the Meridian plugin).
You may want to give the Generic Serial plugin a shot before trying to write your own. For simple protocols, it can do all of the work. If you need more advanced handling of response strings, you can use VB Script Devices to parse the response data.
You may want to give the Generic Serial plugin a shot before trying to write your own. For simple protocols, it can do all of the work. If you need more advanced handling of response strings, you can use VB Script Devices to parse the response data.
I would see this as being a good thing to have, not something to avoid. This allows the HouseBot Device to always be in sync with the actual physical device regardless of how the device is controlled. For example, if you have a Volume Property in the HouseBot Device, you would want the volume level (number) to display the correct value whether the volume was changed through HouseBot or by the physical device....the DSP is reporting status on the serial port every time it changes, even if the change is not initiated from the serialport.
Scott