SmartThings <--> Digitalstrom device connector
103 views
Skip to first unread message
Hendrik Kluge
Sep 28, 2018, 11:49:16 AM9/28/18
to plan44_vdcd
Hi,
As a private project I'm working on connecting/integrating my SmartThings sensors to my DigitalStrom system. Target for first step is to integrate the SmartThings "Multipurpose Sensors" (https://www.smartthings.com/products/smartthings-multipurpose-sensor) as simple "open" / "close" sensors into DS. (next step maybe even the temperature and vibration sensor)
With a bit of help from Christoph Hofmann I managed to get the sensor already working via his DS IFTTT tool. (via user defined actions & user defined states). He suggested me to use plan44 to have a much better integration with DS.
Therefore I setup the plan44 open source vdcd on my RPI 3. Now I'm wondering which would be the best type of group or Sensor to setup in vdcd to represent the door sensor (as first step 2 states are fine / “open” & “close”, next step multi sensor with also temperature and vibration sensor).
Up to now I tried “green” / group 7 and “red” / group 6, yet I couldn’t use the sensors in DS to trigger any user defined action.
Another question which came up reading the user manual: how is the “tag name” derived / how can I tell which letter to use to communicate with the virtual sensor/device?
from “plan44 vdcd external device API.pdf”, page 21
[..]
telnet localhost 8999
Now copy and paste (single line!!) a simple init message defining a light button:
{'message':'init','protocol':'simple','uniqueid':'experiment42','buttons': [{'buttontype':1,'group':1,'element':0}]}
[..]
B0=250 For dimming, the button can be held down...
B0=1
[..]
Where is “B0” coming from/how to tell which “tag” to be used for communicating with the sensor
Thanks for your help
Hendrik
Lukas Zeller
Sep 28, 2018, 2:58:17 PM9/28/18
to Hendrik Kluge, 'Hendrik Kluge' via plan44_vdcd
Hi Hendrik,
> On 28 Sep 2018, at 17:49, 'Hendrik Kluge' via plan44_vdcd <plan4...@googlegroups.com> wrote:
> As a private project I'm working on connecting/integrating my SmartThings sensors to my DigitalStrom system. Target for first step is to integrate the SmartThings "Multipurpose Sensors" (https://www.smartthings.com/products/smartthings-multipurpose-sensor) as simple "open" / "close" sensors into DS. (next step maybe even the temperature and vibration sensor)
>
> With a bit of help from Christoph Hofmann I managed to get the sensor already working via his DS IFTTT tool. (via user defined actions & user defined states). He suggested me to use plan44 to have a much better integration with DS.
>
> Therefore I setup the plan44 open source vdcd on my RPI 3. Now I'm wondering which would be the best type of group or Sensor to setup in vdcd to represent the door sensor (as first step 2 states are fine / “open” & “close”, next step multi sensor with also temperature and vibration sensor).
> Up to now I tried “green” / group 7 and “red” / group 6, yet I couldn’t use the sensors in DS to trigger any user defined action.
>
Only with type 8 (black) sensors you can configure the sensor function in the dSS (in the dSS -> Hardware->Edit Device Properties). If you set it to "App mode", then you can use it freely for any user defined actions.
But you can create a sensor of another color (color does not technically matter for sensor inputs, but can help users to understand the purpose) and assign it the correct system function, by setting "inputtype" in the init message (e.g. to 14 for door contact).
> Another question which came up reading the user manual: how is the “tag name” derived / how can I tell which letter to use to communicate with the virtual sensor/device?
>
> from “plan44 vdcd external device API.pdf”, page 21
If you only announce a single device per connection (i.e. open a new connection for every device) then you don't need any tags.
If you want to manage multiple devices in a single connection, then you need tags - just choose a different one for each device.
>> telnet localhost 8999
>>
>>
>> Now copy and paste (single line!!) a simple init message defining a light button:
>>
>> {'message':'init','protocol':'simple','uniqueid':'experiment42','buttons': [{'buttontype':1,'group':1,'element':0}]}
>>
>> [..]
>>
>>
>> B0=250
>>
>> For dimming, the button can be held down...
>>
>> B0=1
>>
>>
>> [..]
>
> Where is “B0” coming from/how to tell which “tag” to be used for communicating with the sensor
See "Messages from device(s) to vdcd" in the PDF
The "B" (Button) messages are for buttons.
If you define a binary input, not a button, you need to use the "I" (Input) messages:
To set the input active, type
I0=1
to set it inactive, type
I0=0
If you have multiple inputs in one device, then use I1, I2, I3... etc. for the 2nd, 3rd, 4th etc. input
In case you have multiple devices in one connection, then you need to put the tag before the commands, like:
mytag:I0=1
Hope this helps!
Best Regards,
Lukas
> On 28 Sep 2018, at 17:49, 'Hendrik Kluge' via plan44_vdcd <plan4...@googlegroups.com> wrote:
> As a private project I'm working on connecting/integrating my SmartThings sensors to my DigitalStrom system. Target for first step is to integrate the SmartThings "Multipurpose Sensors" (https://www.smartthings.com/products/smartthings-multipurpose-sensor) as simple "open" / "close" sensors into DS. (next step maybe even the temperature and vibration sensor)
>
> With a bit of help from Christoph Hofmann I managed to get the sensor already working via his DS IFTTT tool. (via user defined actions & user defined states). He suggested me to use plan44 to have a much better integration with DS.
>
> Therefore I setup the plan44 open source vdcd on my RPI 3. Now I'm wondering which would be the best type of group or Sensor to setup in vdcd to represent the door sensor (as first step 2 states are fine / “open” & “close”, next step multi sensor with also temperature and vibration sensor).
> Up to now I tried “green” / group 7 and “red” / group 6, yet I couldn’t use the sensors in DS to trigger any user defined action.
>
But you can create a sensor of another color (color does not technically matter for sensor inputs, but can help users to understand the purpose) and assign it the correct system function, by setting "inputtype" in the init message (e.g. to 14 for door contact).
> Another question which came up reading the user manual: how is the “tag name” derived / how can I tell which letter to use to communicate with the virtual sensor/device?
>
> from “plan44 vdcd external device API.pdf”, page 21
If you want to manage multiple devices in a single connection, then you need tags - just choose a different one for each device.
>> telnet localhost 8999
>>
>>
>> Now copy and paste (single line!!) a simple init message defining a light button:
>>
>> {'message':'init','protocol':'simple','uniqueid':'experiment42','buttons': [{'buttontype':1,'group':1,'element':0}]}
>>
>> [..]
>>
>>
>> B0=250
>>
>> For dimming, the button can be held down...
>>
>> B0=1
>>
>>
>> [..]
>
> Where is “B0” coming from/how to tell which “tag” to be used for communicating with the sensor
The "B" (Button) messages are for buttons.
If you define a binary input, not a button, you need to use the "I" (Input) messages:
To set the input active, type
I0=1
to set it inactive, type
I0=0
If you have multiple inputs in one device, then use I1, I2, I3... etc. for the 2nd, 3rd, 4th etc. input
In case you have multiple devices in one connection, then you need to put the tag before the commands, like:
mytag:I0=1
Hope this helps!
Best Regards,
Lukas
Lukas Zeller
Sep 29, 2018, 5:34:40 AM9/29/18
to 'Hendrik Kluge' via plan44_vdcd, Hendrik Kluge
Hi Hendrik,
> On 29 Sep 2018, at 07:54, Hendrik Kluge <hendri...@googlemail.com> wrote:
>
> Thanks for your feedback Lukas!
>
> I played a bit with the sensor creation in vdcd, yet didn't manage to get the door sensor right. I tried a simple
>
> {'message':'init','protocol':'simple','uniqueid':'abc123','name':'myDoorSensor', 'group':8}
With this, you create a device with no inputs and no outputs...
> yet I couldn't change to "App mode". All that DSS is showing is:
> <grafik.png>
> (also the devices was not usable for any user defined action)
...that's why it can't do more than show up in the dSS' list ;-)
Basically, a dS device can have
- zero, one or multiple output channels. Switches and Dimmers have a single channel, jalousies and color lights need more than one channel
- zero, one or two buttons. Up/Down-Type rockers usually are modelled as two buttons in a device
- zero, one or more digital (binary) inputs. These are for yes/no type sensors like door or window contacts.
- zero, one or more sensor inputs. These are for numeric values like temperature, humidity, illumination etc.
> Then I tried a bit more complex to at least limit the valid states to "open" and "closed", yet the Sensor was still on numeric basis
>
> {'message':'init','protocol':'simple','uniqueid':'abc123','name':'myDoorSensor', 'group':8, 'vendorname':"SmartThings", 'sensors':[{'sensortype':0,'hardwarename':'myDoorSensor2','type':'string', 'states':['open','!close'] }] }
There's no absolute freedom in modelling your device. You need to stick closely with what the dS model actually offers!
There's no such thing as sensors or inputs with named states. (States exist in "single devices", but these are a completely different concept for complex household machines like washing machine, dryers, coffee machine etc. and these type of devices need a specific dSS-side app to work at all)
First of all, a door contact is a yes/no type, so you need to model it as a digital (binary) input object (see page 11 of the external device API PDF).
If you initialize a sensor with this:
{'message':'init','protocol':'simple','uniqueid':'abc123','name':'myDoorSensor', 'group':8, 'vendorname':"SmartThings", 'inputs':[{'inputtype':14,'hardwarename':'myDoorSensor2'}] }
then you get a door contact sensor. Note that you need to move it into a real room in dSS (out of the "New Devices" room it is initially assigned to). Then you can use it in "Event Responder" or "User Defined States" as a trigger for an action or a state change, resp. (in "User defined actions", sensors/inputs can be used as additional conditions).
> S0=1 --> [2018-09-29 05:41:23.571 N] vdSD ADE2D1176D0C5454803CA39C00C41AE400 (myDoorSensor): Sensor[0] undefined 'myDoorSensor2' reports NEW value = 1.000
This would be a correct statement for an actual sensor (like a temperature), but not for a binary input.
What you want for a door contact is a binary input. So with the init message above, you'd need to do use
I0=1
and
I0=0
to switch the input state.
> S0='open' --> [2018-09-29 05:41:23.571 N] vdSD ADE2D1176D0C5454803CA39C00C41AE400 (myDoorSensor): Sensor[0] undefined 'myDoorSensor2' reports NEW value = 0.000
> S0='close' --> [nothing / no feedback]
Can't work, no named states exist at this point, see above.
> On the "tags":
> I couldn't find a list of letters, which are used to communicate, so what I know up to now is:
> I[n] - Input
> S[n] - Sensor
> B[n] - Button
> C[n] - Output (I believe C stands for "Controller"?)
C stands for channel.
See the two chapters on device communication after the initialisation: "Messages from vdcd to device(s)" and "Messages from device(s) to vdcd". The former is only for devices that have output (channels!), the latter is what you need to look at for inputs, buttons and sensors. These two chapters list ALL available messages.
About "tags": these are extra labels *you* specify in the init message to keep messages to/from multiple devices using the same TCP/IP connection apart. As long as you only use a single device (recommended for first experiments), you need no tags at all.
Best Regards,
Lukas
> On 29 Sep 2018, at 07:54, Hendrik Kluge <hendri...@googlemail.com> wrote:
>
> Thanks for your feedback Lukas!
>
> I played a bit with the sensor creation in vdcd, yet didn't manage to get the door sensor right. I tried a simple
>
> {'message':'init','protocol':'simple','uniqueid':'abc123','name':'myDoorSensor', 'group':8}
With this, you create a device with no inputs and no outputs...
> yet I couldn't change to "App mode". All that DSS is showing is:
> <grafik.png>
> (also the devices was not usable for any user defined action)
...that's why it can't do more than show up in the dSS' list ;-)
Basically, a dS device can have
- zero, one or multiple output channels. Switches and Dimmers have a single channel, jalousies and color lights need more than one channel
- zero, one or two buttons. Up/Down-Type rockers usually are modelled as two buttons in a device
- zero, one or more digital (binary) inputs. These are for yes/no type sensors like door or window contacts.
- zero, one or more sensor inputs. These are for numeric values like temperature, humidity, illumination etc.
> Then I tried a bit more complex to at least limit the valid states to "open" and "closed", yet the Sensor was still on numeric basis
>
> {'message':'init','protocol':'simple','uniqueid':'abc123','name':'myDoorSensor', 'group':8, 'vendorname':"SmartThings", 'sensors':[{'sensortype':0,'hardwarename':'myDoorSensor2','type':'string', 'states':['open','!close'] }] }
There's no absolute freedom in modelling your device. You need to stick closely with what the dS model actually offers!
There's no such thing as sensors or inputs with named states. (States exist in "single devices", but these are a completely different concept for complex household machines like washing machine, dryers, coffee machine etc. and these type of devices need a specific dSS-side app to work at all)
First of all, a door contact is a yes/no type, so you need to model it as a digital (binary) input object (see page 11 of the external device API PDF).
If you initialize a sensor with this:
{'message':'init','protocol':'simple','uniqueid':'abc123','name':'myDoorSensor', 'group':8, 'vendorname':"SmartThings", 'inputs':[{'inputtype':14,'hardwarename':'myDoorSensor2'}] }
then you get a door contact sensor. Note that you need to move it into a real room in dSS (out of the "New Devices" room it is initially assigned to). Then you can use it in "Event Responder" or "User Defined States" as a trigger for an action or a state change, resp. (in "User defined actions", sensors/inputs can be used as additional conditions).
> S0=1 --> [2018-09-29 05:41:23.571 N] vdSD ADE2D1176D0C5454803CA39C00C41AE400 (myDoorSensor): Sensor[0] undefined 'myDoorSensor2' reports NEW value = 1.000
This would be a correct statement for an actual sensor (like a temperature), but not for a binary input.
What you want for a door contact is a binary input. So with the init message above, you'd need to do use
I0=1
and
I0=0
to switch the input state.
> S0='open' --> [2018-09-29 05:41:23.571 N] vdSD ADE2D1176D0C5454803CA39C00C41AE400 (myDoorSensor): Sensor[0] undefined 'myDoorSensor2' reports NEW value = 0.000
> S0='close' --> [nothing / no feedback]
Can't work, no named states exist at this point, see above.
> On the "tags":
> I couldn't find a list of letters, which are used to communicate, so what I know up to now is:
> I[n] - Input
> S[n] - Sensor
> B[n] - Button
> C[n] - Output (I believe C stands for "Controller"?)
C stands for channel.
See the two chapters on device communication after the initialisation: "Messages from vdcd to device(s)" and "Messages from device(s) to vdcd". The former is only for devices that have output (channels!), the latter is what you need to look at for inputs, buttons and sensors. These two chapters list ALL available messages.
About "tags": these are extra labels *you* specify in the init message to keep messages to/from multiple devices using the same TCP/IP connection apart. As long as you only use a single device (recommended for first experiments), you need no tags at all.
Best Regards,
Lukas
Hendrik Kluge
Oct 2, 2018, 2:10:54 AM10/2/18
to plan4...@googlegroups.com
Top,
danke! Hat funktioniert!
Jetzt habe ich noch ein wenig weitergespielt, dabei kam noch ein Problem auf:
SmartThings schickt mir die nötigen Daten via Http/JSON. Entsprechend habe ich deinen "json_api_forwarder" (aus dem Github Projekt) genutzt, um das JSON Objekt in vcdc zu bekommen.
vdcd rufe ich so auf:
~/ds/vdcd/vdcd --sqlitedir ~/ds/data --externaldevices 8999
--productname "SmartthingsBridge" --productversion "0.5" --vdsmnonlocal
--icondir ~/ds/vdcd/icons --vdsmport 8090
Das ankommende JSON Objekt sieht so aus:
{"message":"init","protocol":"simple","uniqueid":"fbc12647-e692-4911-aaa4-578424d14036","name":"Door Sensor","group":8,"vendorname":"SmartThings","iconname":"SmartThings_icon","inputs":{"inputtype":14,"hardwarename":"Door Sensor"}}
Der $request der via fsockopen weitergeleitet wird (Zeile 52 in deiner api.php) hat diesen Inhalt:
{"method":"POST","uri":"","data":{"message":"init","protocol":"simple","uniqueid":"fbc12647-e692-4911-aaa4-578424d14036","name":"Door Sensor","group":8,"vendorname":"SmartThings","iconname":"SmartThings_icon","inputs":{"inputtype":14,"hardwarename":"Door Sensor"}}}
Direkt danach stürzt die vdcd leider mit dieser Fehlermeldung ab:
[2018-10-02 07:53:10.110 E] vDC API connection closing, reason: Connection closed (SocketComm:6)
[2018-10-02 07:53:10.110 E] vDC API connection closing, reason: Connection closed (SocketComm:6)
[2018-10-02 07:53:10.111 N] vDC API connection (not yet in session) closed
Speicherzugriffsfehler
Hast du eine Idee, woran das liegen kann bzw. wie ich das beheben kann?
Zweite, eher unwichtige Frage: Ich würde gerne eigene Icons verwenden. Ich habe sie in das Verzeichnis vom RPI
~/ds/vdcd/icon gelegt und beim Aufruf der vdcd entsprechend angegeben. Leider zieht sich DS die Icons wohl nicht vom RPI, oder? Wie könnte ich eigene Icons integrieren?
Gruß und danke für deine Hilfe
Hendrik
PS.: Ich weiß nicht, ob Christoph dir meine Anmerkungen zur Installationsanleitung weitergeleitet hatte, oder nicht - daher nochmal auf diesem Wege.
In deinem Installations-Skript für die plan44 Bridge / Open Source Projekt fehlten noch ein paar Pakete für das erfolgreiche Compilieren. Hier die überarbeitete Version, die ich genutzt habe, um vdcd bei mir zu installieren/compilieren. Basis war/ist ein Raspian lite.
In deinem Installations-Skript für die plan44 Bridge / Open Source Projekt fehlten noch ein paar Pakete für das erfolgreiche Compilieren. Hier die überarbeitete Version, die ich genutzt habe, um vdcd bei mir zu installieren/compilieren. Basis war/ist ein Raspian lite.
$SUPER apt-get --assume-yes install git automake libtool autoconf g++ make libjson-c-dev libsqlite3-dev protobuf-c-compiler libprotobuf-c-dev libboost-dev libi2c-dev libssl-dev libavahi-core-dev libavahi-client-dev libi2c-dev libavahi-core7 libjson-c-dev libsqlite3-dev protobuf-c-compiler libprotobuf-c-dev libboost-dev libi2c-dev libssl-dev libavahi-core-dev libavahi-client-dev libssl-dev libjson-c-dev sqlite3 libsqlite3-dev libprotobuf-c-dev
(anbei das gesamte Skript, für die einfach, komfortable Installation/Compilierung "from scratch" - feel free to use it)
--
Sie erhalten diese Nachricht, weil Sie Mitglied der Google Groups-Gruppe "plan44_vdcd" sind.
Wenn Sie sich von dieser Gruppe abmelden und keine E-Mails mehr von dieser Gruppe erhalten möchten, senden Sie eine E-Mail an plan44_vdcd...@googlegroups.com.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an plan4...@googlegroups.com.
Gruppe besuchen: https://groups.google.com/group/plan44_vdcd
Besuchen Sie https://groups.google.com/d/msgid/plan44_vdcd/EAF916A6-2B23-4D2D-9200-DD0B8B34913A%40plan44.ch, um diese Diskussion im Web anzuzeigen.
Weitere Optionen: https://groups.google.com/d/optout
Lukas Zeller
Oct 2, 2018, 11:28:33 AM10/2/18
to 'Hendrik Kluge' via plan44_vdcd, Hendrik Kluge
Hallo Hendrik,
> On 2 Oct 2018, at 08:10, 'Hendrik Kluge' via plan44_vdcd <plan4...@googlegroups.com> wrote:
>
> Top,
> danke! Hat funktioniert! Jetzt habe ich noch ein wenig weitergespielt, dabei kam noch ein Problem auf:
>
> SmartThings schickt mir die nötigen Daten via Http/JSON. Entsprechend habe ich deinen "json_api_forwarder" (aus dem Github Projekt) genutzt, um das JSON Objekt in vcdc zu bekommen.
Der json_api_forwarder ist für die JSON-Variante der vDC-API gedacht, also die API, die auch dSS/vdSM verwenden (allerdings nicht in im JSON-Format, sondern protobuf). Als JSON-Variante existiert sie im vdcd, weil darüber z.B. die Weboberfläche der P44-DSB läuft. Der "json_api_forwarder" ist dazu da, um mit einem normalen PHP/Apache-Webserver z.B. eine Web-API zu machen. In der P44-DSB brauchts den nicht, weil dort der spezielle mg44-Webserver läuft, welcher diesen forwarder schon eingebaut hat.
Das alles hat aber GAR NICHTS mit der "external device API" zu tun, die Du ansprechen willst. Diese versteht die gewrappten HTTP-Requests des json_api_forwarder nicht.
Du kannst schon PHP-Code ähnlich dem ab der Kommentarzeile "// now call" des json_api_forwarder verwenden, aber Du musst die Daten an den external device API Port (8999, bzw. wie mit --externaldevices angegeben) senden, nicht an 8090.
1:1 so, wie Du sie auch im manuellen Test mit telnet sendest, also alles auf einer Zeile, mit einem Zeilenende am Schluss.
Und, ganz wichtig: Du hast mit --vdsmport die API für das digitalSTROM-System auf den Port gelegt, auf dem normalerweise die lokale Web-UI die JSON-API erwartet.
> Direkt danach stürzt die vdcd leider mit dieser Fehlermeldung ab:
:-( Weil da die APIs komplett durcheinandergeraten sind.
--vdsmport ist eine Protobuf-API, reserviert für den Zugriff des dS-Systems (vdSM). Die sollte ohne triftige Gründe auf dem Default 8340 belassen werden (was der Fall ist wenn man gar nichts spezifiziert)
--cfgapiport ist die API, die der json_api_forwarder bzw. die Weboberfläche in der P44-DSB anspricht, und dererwartet diese auf Port 8090. Kann man weglassen, wenn keine Web-UI im Spiel ist.
--external ist die external device API, üblicherweise (in den Beispielen und in P44-DSB) auf Port 8999. Auf diesen Port kann man mit telnet zugreifen, oder mit sonst irgend einer Socket-Connection (z.B. aus PHP mit fsockopen/fwrite). Solange das externe Device leben soll, muss auch die Connection offen gehalten werden.
> Zweite, eher unwichtige Frage: Ich würde gerne eigene Icons verwenden. Ich habe sie in das Verzeichnis vom RPI ~/ds/vdcd/icon gelegt und beim Aufruf der vdcd entsprechend angegeben. Leider zieht sich DS die Icons wohl nicht vom RPI, oder?
Doch.
> Wie könnte ich eigene Icons integrieren?
Erstens: von dem Pfad aus, den Du mit --icondir angibst, müssen die Icons in einem Subdirectory namens icon16 liegen. Das deswegen, damit man in Zukunft auch höher aufgelöste Icons unterstützen könnte.
Also wenn Du --icondir /home/meinname/ds/vdcd/icon angibst, müssen die Icons (als 16*16pixel .png) im Ordner /home/meinname/ds/vdcd/icon/icon16 liegen.
Zweitens: in der "init" message deiner devices musst du "iconname" als Basisname angeben.
Der vdcd versucht dann zuerst das file <iconname>_<farbe>.png zu finden, je nach digitalSTROM-Farbe des Geräts. Wenn dieses nicht existiert, wird <iconname>_other.png verwendet.
Wenn Du also Dein eigenes icon "meinicon_other.png" nennst, dann musst Du "meinicon" als "iconname" angeben.
Wenn Du Farbvarianten unterstützen willst, dann nenne die Files "meinicon_yellow.png", "meinicon_black.png", "meinicon_red.png" etc.
BTW: ~ sollte als Argument bei vdcd eher nicht verwendet werden, denn das heisst "aktueller user", und das ist oft später dann nicht der selbe wie wenn man das auf der Commandline erstmals auspobiert. Besser /home/meinname/ds/vdcd/icon...
Gruss von Lukas
> On 2 Oct 2018, at 08:10, 'Hendrik Kluge' via plan44_vdcd <plan4...@googlegroups.com> wrote:
>
> Top,
> danke! Hat funktioniert! Jetzt habe ich noch ein wenig weitergespielt, dabei kam noch ein Problem auf:
>
> SmartThings schickt mir die nötigen Daten via Http/JSON. Entsprechend habe ich deinen "json_api_forwarder" (aus dem Github Projekt) genutzt, um das JSON Objekt in vcdc zu bekommen.
Das alles hat aber GAR NICHTS mit der "external device API" zu tun, die Du ansprechen willst. Diese versteht die gewrappten HTTP-Requests des json_api_forwarder nicht.
Du kannst schon PHP-Code ähnlich dem ab der Kommentarzeile "// now call" des json_api_forwarder verwenden, aber Du musst die Daten an den external device API Port (8999, bzw. wie mit --externaldevices angegeben) senden, nicht an 8090.
1:1 so, wie Du sie auch im manuellen Test mit telnet sendest, also alles auf einer Zeile, mit einem Zeilenende am Schluss.
Und, ganz wichtig: Du hast mit --vdsmport die API für das digitalSTROM-System auf den Port gelegt, auf dem normalerweise die lokale Web-UI die JSON-API erwartet.
> Direkt danach stürzt die vdcd leider mit dieser Fehlermeldung ab:
--vdsmport ist eine Protobuf-API, reserviert für den Zugriff des dS-Systems (vdSM). Die sollte ohne triftige Gründe auf dem Default 8340 belassen werden (was der Fall ist wenn man gar nichts spezifiziert)
--cfgapiport ist die API, die der json_api_forwarder bzw. die Weboberfläche in der P44-DSB anspricht, und dererwartet diese auf Port 8090. Kann man weglassen, wenn keine Web-UI im Spiel ist.
--external ist die external device API, üblicherweise (in den Beispielen und in P44-DSB) auf Port 8999. Auf diesen Port kann man mit telnet zugreifen, oder mit sonst irgend einer Socket-Connection (z.B. aus PHP mit fsockopen/fwrite). Solange das externe Device leben soll, muss auch die Connection offen gehalten werden.
> Zweite, eher unwichtige Frage: Ich würde gerne eigene Icons verwenden. Ich habe sie in das Verzeichnis vom RPI ~/ds/vdcd/icon gelegt und beim Aufruf der vdcd entsprechend angegeben. Leider zieht sich DS die Icons wohl nicht vom RPI, oder?
> Wie könnte ich eigene Icons integrieren?
Also wenn Du --icondir /home/meinname/ds/vdcd/icon angibst, müssen die Icons (als 16*16pixel .png) im Ordner /home/meinname/ds/vdcd/icon/icon16 liegen.
Zweitens: in der "init" message deiner devices musst du "iconname" als Basisname angeben.
Der vdcd versucht dann zuerst das file <iconname>_<farbe>.png zu finden, je nach digitalSTROM-Farbe des Geräts. Wenn dieses nicht existiert, wird <iconname>_other.png verwendet.
Wenn Du also Dein eigenes icon "meinicon_other.png" nennst, dann musst Du "meinicon" als "iconname" angeben.
Wenn Du Farbvarianten unterstützen willst, dann nenne die Files "meinicon_yellow.png", "meinicon_black.png", "meinicon_red.png" etc.
BTW: ~ sollte als Argument bei vdcd eher nicht verwendet werden, denn das heisst "aktueller user", und das ist oft später dann nicht der selbe wie wenn man das auf der Commandline erstmals auspobiert. Besser /home/meinname/ds/vdcd/icon...
Gruss von Lukas
Reply all
Reply to author
Forward
0 new messages