EibLib/Ip & EibNet/IP

[Warichet]

Can you tell a bit more about what you call "GroupRead". Is it the groupread.php script I have written?

Yes.
I'm using both of your scripts throughout the application and it works fine.

One minor modification, I've repackaged your code to make it a function to make it re-usable, but don't think it would alter the behaviour, unless I've to cast the return code to a single byte ?

I use it this way

$status = GroupRead("127.0.0.1",$ga2);
echo "<!-- Status= ".$status. "-->";

The end of the function is like this

  $con->EIBClose();
  return $return;     // return the EIB status, 0=Off, 1=On, xx-dimmer value
  }
?>

[jef2000]

When I read it with GroupRead, I get "-1124" ?!? ûû that doesn't fit in one Byte !

Hi,

Can you tell a bit more about what you call "GroupRead". Is it the groupread.php script I have written? I don't think so because it's displaying hexadecimal values. Or the groupread example program of eibd? I don't think so, because it's not supposed to return any value. Then what else could it be?

Regards,

Jean-François

[Warichet]

Hi Jean-François,

No, there is no trick to know what datatype is transmitted on the bus. This information is not transmitted.

Thank you for the quick and to-the-point reply. I confirms what I expected

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

OK, I'm learning a bit everyday...

Nevertheless, I'm still puzzled with what I get.
A concrete example: dimmer Merten 649315 4x150W
The status feedback data is 1Byte.
When I read it with GroupRead, I get "-1124" ?!? ûû that doesn't fit in one Byte !
So I guess either my test is wrong or some conversion has to be done.
Any hint ?
NB: the Visu duly shows "49%" which is the actual state of the brightness. I can't see any link between 49 and 1124.
Well, after making several tests, I'll try a conclusion
drop the -1 of -1124, so it's 124
124 = 49% of 255

[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

[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

[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.

[aggie89go]

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

Regards,
Marc

[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

[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]

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]

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

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]

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]

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 ;-)

[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...