EibLib/Ip & EibNet/IP

[Warichet]

The only difference you will see is on the command line when you start eibd.

What would be the recommended parameters to start eibd ?

I guess there is something wrong with my setup, as I'm unable to issue the command "groupswrite ip:127.0.0.1 0/1/31 1" (hence I draw the wrong conclusions).

Thank you

[jef2000]

What would be the recommended parameters to start eibd ?

I guess there is something wrong with my setup, as I'm unable to issue the command "groupswrite ip:127.0.0.1 0/1/31 1" (hence I draw the wrong conclusions).

Thank you

Hi

You said:
"Indeed, so far I can switch a lamp On/Off with the phone's TouchScreen."
I assume you are able to do it with eibd... Ah, but perhaps you are using unix sockets intead of inet sockets...
There are 2 different ways to access eibd with client library. If you start eibd with -u option, you are using unix sockets and must use commands like:
groupswrite local:/tmp/eib 1/1/11 1
to switch devices on/off.
If you start eibd with -i option, you are using inet (aka tcp) sockets and must use commands like:
groupswrite ip:127.0.0.1 1/1/11 1
to switch devices on/off.

I tried to write a couple of examples with the php interface to see how it works.
groupswrite.php:

<?php
require('eibclient.php');

$con = new EIBConnection($argv[1]);
$dest = split('/', $argv[2]);
$dest_addr = (($dest[0] & 0x01f) << 11) | (($dest[1] & 0x07) << 8) | (($dest[2] & 0xff));

if ($con->EIBOpenT_Group ($dest_addr, 1) == -1)
    exit("Connect failed");
$data = chr(0).chr(0x80 | $argv[3]);
printf($data);
$len = $con->EIBSendAPDU($data);
if ($len == -1)
    exit("Request failed");
print("Send request\n");

$con->EIBClose();

?>

To switch on group 1/1/11, start eibd with -i option and execute command:
php groupswrite.php 127.0.0.1 1/1/11 1

groupread.php:

<?php
require('eibclient.php');

$con = new EIBConnection($argv[1]);
$dest = split('/', $argv[2]);
$dest_addr = (($dest[0] & 0x01f) << 11) | (($dest[1] & 0x07) << 8) | (($dest[2] & 0xff));

if ($con->EIBOpenT_Group ($dest_addr, 0) == -1)
    exit("Connect failed");
$data = chr(0).chr(0);
$len = $con->EIBSendAPDU($data);
if ($len == -1)
    exit("Request failed");
print("Send request\n");

        
while (1)    {
        $data = new EIBBuffer();
        $src = new EIBAddr();
    $len = $con->EIBGetAPDU_Src($data, $src);
    if ($len == -1)
        exit("Read failed");
    if ($len < 2)
        exit("Invalid Packet");
    $buf = unpack("C*", $data->buffer);
    if ($buf[1] & 0x3 || ($buf[2] & 0xC0) == 0xC0) {
        printf("Error: Unknown APDU: %02X%02X\n", $buf[1], $buf[2]);
    }
    else if (($buf[2] & 0xC0) == 0x40) {
        if ($len == 2) {
            printf ("%02X\n", $buf[2] & 0x3F);
        }
        else {
            for ($i=3; $i<=$len; $i++)
                            printf ("%02X", $buf[$i]);
            printf ("\n");
        }
        break;
    }
}

$con->EIBClose();

?>

To get the actual value of group 1/1/11, start eibd with -i option and execute command:
php groupread.php 127.0.0.1 1/1/11

Best regards,

Jean-François

[Warichet]

Hi,

I'm making some (very little) progress
The command:
eibd -d -D -S -T -i bcu1:/dev/tty
does indeed start the daemon, as seen by:
ps aux | grep eibd
the command:
groupswrite ip:127.0.0.1 0/1/31 1
doesn't return an error anymore .... I get
"Send request"
but nothing happens.

So, there is still a mistake in my setup, I guess it has to do with the eibd startup parameters.

Anyone be so kind to post the command line about how to start eibd, with IP enabled on a BCU1.

Thank you for any hint.

[Chris M.]

groupswrite ip:127.0.0.1 0/1/31 1
doesn't return an error anymore .... I get
"Send request"
but nothing happens.

Are you sure that an actor is using the address 0/1/31 that can handle the 1?

If you are using a bus monitor you should see the execution of the groupswrite. Or you could try to run

vbusmonitor1 ip:127.0.0.1

This monitor should show you the decoded messages on your current bus. If it works, then sending should work as well. If it doesn't work, sending won't work...

[Warichet]

Are you sure that an actor is using the address 0/1/31 that can handle the 1?

Yes, Sir !

If you are using a bus monitor you should see the execution of the groupswrite.

I use the HS monitor, and I can turn the lamp On/Off by writing a 0/1 to GA 0/1/31

I started the ETS monitor, just to please you, and quite logically, I don't see anything. Otherwise, as you mentionned, it would have worked.

I'm focussing on eibd, as the IP part has never worked. I'm slowly reaching the end, as almost all possibilities are exhausted ... or one of my fundamental assumptions is wrong.
Would someone be so kind to provide me with an eibd, compiled for a Pentium (Toshiba Tecra M2, Centrino) ?

Thank you for your help

Forgot to mention
vbusmonitor1 ip:127.0.0.1 does display a line
LPDU blabla 01
seems to be OK ;-)

[makki]

Theres one thing wrong in the commandline above. If you want to use BCU1 the parameter for eibd is something like "/dev/eib0" not /dev/ttyS0.

While trying to find out wether anything works at all, it's easier to keep in foreground ("eibd -i -u -t 1023 bcu1:/dev/eib0"), if there's some traffic on your bus you should see some telegrams there.
In short steps, assume connected to Com1 / ttyS0:
- "setserial /dev/ttyS0 uart none" as root
- make sure the /dev/eib0 exists (if not, goto REAME, mknod)
- call "bcuaddrtab bcu1:/dev/eib0" if it returns anything else then "Size:0" something is wrong.

or one of my fundamental assumptions is wrong.

That's it, the assumption that using a BCU1 for anything else than first finding about how complicated it *could* be and nearly anything that can go wrong
The driver is the most fiddly and complicated to use of all due to needing a kernel-module and the interface being very timing-critical. And then even when it works, producing problems I had with no other backend.
Any other backend as usb, FT1.2, TPUART (or finally a EIBnet/IP Router) simply works without all these hassles.
What your dealing with are most probably not programming/bus/IP issues but simply the fact BCU1 doesn't work as you would.

Would someone be so kind to provide me with an eibd, compiled for a Pentium (Toshiba Tecra M2, Centrino) ?

For eibd there are ready to run packages for major distros on x86, the issue is only with the BCU1 Kernel-driver. This depends on your kernel-version. So one needs to know the version. And yes, if this kernel changes someday the mess starts again If it's Debian, I could provide these but it won't make things much better..

BTW: on a side note, I tried again today to use eibd as IP-Router for the HS. Still the same, massive scan errors. To get further on this I'd first need a capture of a working environment to compare and start to understand what goes wrong here..

Makki

[Warichet]

If you want to use BCU1 the parameter for eibd is something like "/dev/eib0" not /dev/ttyS0.

Ya, that was it Thank you

Any other backend as usb, FT1.2, TPUART (or finally a EIBnet/IP Router) simply works without all these hassles.

I still hope to have the HS behave as a true gateway.... one day ... maybe


I can finally start working on the project.
Thanks again.

[makki]

Fine, so I won't get rid of my Cisco phones for now and wait for the perfect Visu-implementation for them

Makki

[Warichet]

Is it so that the -i and -u options are mutually exclusive ?
The daemon listens to only one type of socket ?

If the above is true, then it's not possible to have eibd respond to all kind of requests, hence a decision has to be made. Is that correct ?

I have a test tool that uses "local:/tmp/eib", which doesn't run anymore, probably due to the way that eibd is started.

[makki]

Is it so that the -i and -u options are mutually exclusive ?

No. -u makes listening on the socket (local:/tmp/eib) -i on IP, I'm using both methods forever.. Maybe permissions, two daemons started, file /tmp/eib left over somehow ?

Makki

[Warichet]

No. -u makes listening on the socket (local:/tmp/eib) -i on IP, I'm using both methods forever..

Thank you, I'll try as well.

About the driver, I'm still loading the driver manually after boot, any means to load it automatically ? (obviously, I'm not a Linux expert )

Thanks a lot

[aggie89go]

Isn't that explained in the Lexikon?
see https://knx-user-forum.de/vbglossar....howentry&id=84

Regards,
Marc

[Warichet]

Hi Jean-François,

I tried to write a couple of examples with the php interface to see how it works.
php groupswrite.php 127.0.0.1 1/1/11 1
php groupread.php 127.0.0.1 1/1/11

I'm coming back from far away ...
I finally managed to run your script, indeed, it works great
Very much appreciated.

I think I still have an inconsistency in my system, that I'm unable to manage due to my lack of experience with Linux.

Thank you very much for your patience with a Linux newbee.

[Warichet]

I tried to write a couple of examples with the php interface to see how it works.

groupread.php:

To get the actual value of group 1/1/11, start eibd with -i option and execute command:
php groupread.php 127.0.0.1 1/1/11

Those 2 functions work fine and helped a lot.
Thanks again.
Now that I'm heading towards the end, I'm refining the code and I'm trying to make it more generic.
So far, I've worked only with On/Off devices, hence status is 1/0.
I'm trying to read the status of a dimmer (or any other variable devices)
How can I handle those data ? not knowing in advance what type it is ?
In ETS we know the data type (EIS 1-14) but here ? there is no context, I guess there is a trick ?

Obviously, I could know which data type a specific device will answer, but that knowledge implies one function per type of data, it's not what I want right now (but maybe there is no other way).

Thank you

[jef2000]

I'm trying to read the status of a dimmer (or any other variable devices)
How can I handle those data ? not knowing in advance what type it is ?
In ETS we know the data type (EIS 1-14) but here ? there is no context, I guess there is a trick ?

Raymond,

No, there is no trick to know what datatype is transmitted on the bus. This information is not transmitted. All the devices interacting with a group address are supposed to know the associated datatype. ETS knows about it and will configure all the devices accordingly. That's one of the reasons why I developed Linknx. EIBD is a great piece of software that allows to access the bus without having to worry if it's RS232, USB, KnxNet/IP , or anything else, but there is still something missing above EIBD where the communication objects can be configured, where one or more groups addresses can be assigned to a communication object, where flags can be set to decide if the object needs to reply to read request, react to write or update requests, or is allowed to transmit on the bus. And of course, where it's possible to set the datatype for each object.

If you want to make something generic that fits in the KNX model, you'll have to deal with that.

Regards,

Jean-François