Vdcd Build Process Is Successfull

[Mustafa Yuce]

Hi Lukas,

Thanks for your help again. At last we have build our project and made executable on raspberry device. We have some questions. We will appreciate if you could answer these questions...

1. When we look at programs running on plan44 device , we see "olavdcd" service not "vdcd". But in previous posts somewhere you said that "OLA will not be required". We couldnt understand it is required or not?

2. When we try to stop the "vdcd" service running on device, it is started somehow by any program. How can we stop "vdcd" service? (Firstly we learn PID by "ps ax | grep vdcd" then run "kill -9 <PID>" command)

3. "vdcd" service running on device is started like this ; 

./olavdcd --redled led.0 --productname P44-DSB-X --productversion 1.0.1.6 --cfgapiport 8091 --sqlitedir /flash --icondir /usr/share/www/icons --huelights --staticdevices -l 5

When we look at the website we see "enocean" devices. But when we run our program (./ArnidoVdcd --redled led.0 --productname P44-DSB-X --productversion 1.0.2.5 --cfgapiport 8091 --sqlitedir /flash --icondir /usr/share/www/icons --huelights --staticdevices -l 5) we cant see any enocean device on the web site. it is about arguments or anything else?

4. We couldnt understand the topology of the program. For example when data come from "enocean" device , is this data transfered to "vdsm"? If it is transfered to "vdsm" which code block send this data. Vice versa do we get data from "vdsm" (eg; set temperature) ? And how do we process this data in which code block? Actually we are wondering how will we start developing by using "vdcd" base classes? And if you can explain packages directions we will be very happy (eg; vdsm -> vdcd -> enocean device or something else)

Kind Regards,

Mustafa Yüce.

[Lukas Zeller]

Hi Mustafa,

> On 14.07.2015, at 09:16, Mustafa Yuce <mustaf...@gmail.com> wrote:
>
> Hi Lukas,
>
> Thanks for your help again. At last we have build our project and made executable on raspberry device. We have some questions. We will appreciate if you could answer these questions...
>
> 1. When we look at programs running on plan44 device , we see "olavdcd" service not "vdcd". But in previous posts somewhere you said that "OLA will not be required". We couldnt understand it is required or not?

OLA is not required, however on P44-DSB-X it *is* included to allow experiments with DMX512 devices.

> 2. When we try to stop the "vdcd" service running on device, it is started somehow by any program. How can we stop "vdcd" service? (Firstly we learn PID by "ps ax | grep vdcd" then run "kill -9 <PID>" command)

I use the "runit" service supervision toolset (http://smarden.org/runit/index.html). So when the vdcd crashes (or gets killed as in your case), it will be restarted automatically by runit.

Use the "sv" command to monitor, start, stop and restart services:

sv stop vdcd

will stop the vdcd.

> 3. "vdcd" service running on device is started like this ;
>
> ./olavdcd --redled led.0 --productname P44-DSB-X --productversion 1.0.1.6 --cfgapiport 8091 --sqlitedir /flash --icondir /usr/share/www/icons --huelights --staticdevices -l 5

This command line is generated from the runit "run" script for vdcd - have a look at /etc/services/vdcd/run

> When we look at the website we see "enocean" devices. But when we run our program (./ArnidoVdcd --redled led.0 --productname P44-DSB-X --productversion 1.0.2.5 --cfgapiport 8091 --sqlitedir /flash --icondir /usr/share/www/icons --huelights --staticdevices -l 5) we cant see any enocean device on the web site. it is about arguments or anything else?

Yes, it's all about arguments on start of vdcd. You can type

vdcd --help

to get a short description of all the arguments available.

On the P44-DSB-X, enocean support is disabled because usually people don't have the needed EnOcean Pi module. When you read through /etc/services/vdcd/run, you'll see that this script either starts vdcd (on a regular P44-DSB-E) or olavdcd (on a P44-DSB-X), and also enables/disables EnOcean, OLA support accordingly.

Just adapt /etc/services/vdcd/run according to your needs.

> 4. We couldnt understand the topology of the program. For example when data come from "enocean" device , is this data transfered to "vdsm"? If it is transfered to "vdsm" which code block send this data. Vice versa do we get data from "vdsm" (eg; set temperature) ? And how do we process this data in which code block? Actually we are wondering how will we start developing by using "vdcd" base classes? And if you can explain packages directions we will be very happy (eg; vdsm -> vdcd -> enocean device or something else)

At digitalSTROM developer days 2013, I had a presentation explaining how vdcd works, including a sample how to build your own (simple) device. The presentation slides are still online: http://alliance.digitalstrom.org/wp-content/uploads/publications/devDays/digitalSTROM%20Developer%20Days%20Presentations%202013/digitalSTROM%20Developer%20Days%20Presentations%202013.zip (and inside this zip file, it's "09 plan44.ch - Building Virtual Devices.pdf"). This should give you an overview of the topology of vdcd.

The idea of vdcd is that you DON'T need to code communication with the vdsm at all. All a custom device class (a subclass of p44::Device) must do is:

- if the device has output channels (usually one, some device may have multiple, like color lamps), implement applyChannelValues(). This method will be called by the framework whenever the output value changes.

- if the device has inputs, call updateInputState() for binary input behaviours, or updateSensorValue() whenever your code receives a new input value.

That's all you need to implement for actually processing input/output data. In addition, you need to initialize the device by setting the digitalstrom color, adding input and/or output behaviour, and set some info like names, value ranges etc.

I would recommend to look at src/deviceclasses/demo and src/deviceclasses/simpleio for examples how to setup devices. For first experiments with your own hardware, I'd just recommend to hijack one of the existing classes, for example consoledevice.cpp or elsnerp03weatherstation.cpp.

The advantage for src/deviceclasses/simpleio devices is that they all are managed by StaticDeviceContainer, so you don't need to implent your own DeviceClassContainer to get started (you can do that later, for example if you want to dynamically scan a bus to "find" your devices). Instead, just look at StaticDeviceContainer::addStaticDevice() and extend it for your own device class. Then you can create your devices from the Web-UI.

hope this helps!

Best Regards,

Lukas