calimero-project / calimero-core Goto Github PK
View Code? Open in Web Editor NEWCore library for KNX network access and management
License: Other
calimero-core's People
Contributors
Stargazers
Watchers
Forkers
raehalme ouaibsky davkick haumacher mschroeer jock71 valemartin pre-martin tlukumaa tobiaswegner vonblubba renelink paischu aheintz tuxedo0801 amedranogil snickermicker glocklueng zombaio zhanjsh jamielitest jianqiaotju kusig jstelwag xpomul lewie delabassee joegana cuda-convnet race666 qgb1151521 vsaindon ascillato imkow afergan derekroy serbande shangyl mdumont-arcom kayhanakbay redirion songzh96 petero-dk ju-kow awgroeneveld gavioto xingke-mo oblaise landyu eliteservice1002 liwangxing dragonxu darthyson as79dev holgerfriedrich frankvandenhurk asbaharoon thomasmirlacher bkhoshbin chenliuyang1989 berhankanbur czboosj kielich89calimero-core's Issues
Maven repo availability
Would it be possible to get a cross platform jar to public maven repos? This would make it much easier to use this library in Java projects.
Sonatype offers a free account for open source project as reported in
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-3.CreateaJIRAticket
What do you think?
Mauro
Many unit tests are not working localy
Hi
I try to run tests on climero core
mvn clean install
And many are failing
- Some of them because they found a knx gateway on my home network
- other reasons
It there any setup to apply before running the test ?
Thx
Christophe
Process communicator
I have a weather station, which sends data to router and then router to Java, who must work continuously and follow all changes in weather, but there is a problem where communication between KNX router and Java application doesn't work when I click Terminate and run the app again.
But when I click ENTER inside console, this line System.out.println("EXIT"); properly ends with this code:
finally {
// we don't need the process communicator anymore, detach it from the link
if (pc != null)
pc.detach();
// close the KNX link
if (knxLink != null)
knxLink.close();
}
So, my question is how to solve this problem? In the future user will not know how to properly end this app and it will run app again and it will not work, so do I need to put this code (finally) somewhere else?
What is about this line: public void detached(DetachEvent e) {}
I need something that will end application properly when user click Terminate, like I have "finally" part in code when it's clicked ENTER.
Please help me!
Please make processCommunicator.write public
Currently, the ProcessCommunicator interface has methods for directly sending certain Java data types with appropriate conversion.
However, the method write(final GroupAddress dst, final Priority p, final DPTXlator t) is private. Making this method public, or adding a public method write(final GroupAddress dst,final DPTXlator t), would allow sending pre-translated data without having to duplicate the ASDU-preparing code.
Changing write for DPTXlator from private to public
Is it possible and wise to change the visibility of following method to public?
ProcessCommunicatorImpl.write(final GroupAddress dst, final Priority p, final DPTXlator t)
If I use the implementation in an external project, it would like to have the full flexibility of the DPTXlator classes for writing to the KNX bus. By now this is not possible due to the private declaration of this method.
Is calimero thread safe?
Sometimes, when the connection to the network is lost I see a thread being 'stuck' in method quit() of class tuwien.auto.calimero.link.EventNotifier.
To get details of where that happens I added some log output to that method and it seems to be the join() call.
The method I used to produce the error is to shutdown the network interface.
11:02:46.268 ERROR tuwien.auto.calimero[:39] - KNXnet/IP Tunneling 192.168.1.251:3671: send disconnect failed
java.io.IOException: Das Argument ist ungültig
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:697)
at tuwien.auto.calimero.knxnetip.ConnectionBase.close(ConnectionBase.java:465)
at tuwien.auto.calimero.knxnetip.ClientConnection$HeartbeatMonitor.run(ClientConnection.java:429)
11:02:46.288 ERROR tuwien.auto.calimero[:39] - KNXnet/IP Tunneling 192.168.1.251:3671: close connection - heartbeat communication failure
java.io.IOException: Das Argument ist ungültig
at java.net.PlainDatagramSocketImpl.send(Native Method)
at java.net.DatagramSocket.send(DatagramSocket.java:697)
at tuwien.auto.calimero.knxnetip.ClientConnection$HeartbeatMonitor.run(ClientConnection.java:406)
11:02:46.290 INFO tuwien.auto.calimero[:43] - process link 192.168.1.251:3671: attached link was closed
11:02:50.045 INFO tuwien.auto.calimero[:43] - link 192.168.1.251:3671: Current Thread: Thread[KNXnet/IP heartbeat monitor,10,main]
11:02:50.046 INFO tuwien.auto.calimero[:43] - link 192.168.1.251:3671: this: Thread[Link notifier,10,main]
11:02:50.046 INFO tuwien.auto.calimero[:43] - link 192.168.1.251:3671: join() requested
11:02:50.047 INFO tuwien.auto.calimero[:43] - link 192.168.1.251:3671: link closed
final void quit()
{
interrupt();
if (currentThread() != this) {
logger.info("Current Thread: "+currentThread());
logger.info("this: "+this);
try {
logger.info("join() requested");
join();
logger.info("join() succeeded");
}
catch (final InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
Same happens btw when I started a separate thread which frequently read from the KNX bus using calimero. When the connection to the bus is lost, that thread is 'stuck'.
Any pointers as to what I'm doing wrong?
2.2-beta classes?
The following dependency leads to a jar without any classes, just html
<groupId>com.github.calimero</groupId>
<artifactId>calimero-core</artifactId>
<version>2.2-beta</version>Or did I miss something?
USB device autodetecting login detects right but opens the wrong device
When it scans for an USB device, if there are more than one HID devices, it detects correctly which is the KNX interface, but then opens the wrong one, in this examples the KNX interface is device 002, it detects it, but then it tries to open device 003 which has already been identified has the wrong one. (note: tested on windows)
C:\driver\calimero_server_jar>java -jar calimero-server.jar server-config.xml
[main] INFO calimero.server - Discovery service network interfaces:
[main] INFO calimero.server - listen on eth3
[main] INFO calimero.server - outgoing eth3
[main] INFO calimero.server - Service container :
[main] INFO calimero.server - IPv4 UDP host 192.168.1.102 port 3671 routing
false
[main] INFO calimero.server - usb connection, TP1 medium, device 1.1.249
[main] INFO calimero.server - GrpAddrFilter []
[main] INFO calimero.server - connect to
[main] INFO calimero.usb - Found KNX devices:
|--Bus 001 Device 002: ID 147b:5120
[main] INFO calimero.usb. - Bus 001 Device 003: ID 0424:2514
[main] WARN calimero.usb. - Interface doesn't look right, no HID class
[main] WARN calimero.usb. - Interface doesn't look right, no HID class
[main] ERROR calimero.link - initial connection attempt
tuwien.auto.calimero.KNXException: open USB connection
at tuwien.auto.calimero.serial.usb.UsbConnection.(UsbConnection.ja
va:411)
at tuwien.auto.calimero.serial.usb.UsbConnection.(UsbConnection.ja
va:380)
at tuwien.auto.calimero.link.KNXNetworkLinkUsb.(KNXNetworkLinkUsb.
java:106)
at tuwien.auto.calimero.server.gateway.SubnetConnector.lambda$openNetwor
kLink$10(SubnetConnector.java:225)
at tuwien.auto.calimero.link.Connector$Link.connect(Connector.java:446)
at tuwien.auto.calimero.link.Connector$Link.(Connector.java:219)
at tuwien.auto.calimero.link.Connector$Link.(Connector.java:176)
at tuwien.auto.calimero.link.Connector.newLink(Connector.java:157)
at tuwien.auto.calimero.server.gateway.SubnetConnector.openNetworkLink(S
ubnetConnector.java:265)
at tuwien.auto.calimero.server.Launcher.connect(Launcher.java:525)
at tuwien.auto.calimero.server.Launcher.run(Launcher.java:455)
at tuwien.auto.calimero.server.Launcher.main(Launcher.java:398)
Caused by: javax.usb.UsbPlatformException: USB error 12: Can't open device Bus 0
01 Device 003: ID 0424:2514: Operation not supported or unimplemented on this pl
atform
Multiple networkinterfaces on windows
I have a nasty problem with one of my customer's installations. The symptoms:
- calimero is not able to receive any KNX telegram via routing or tunneling
- No telegram sent by calimero (either via routing or tunneling) is received on the KNX bus
- the used tunneling/routing knx interface is working with other tools (on other machines)
I think I found the root-cause: The customer is having multiple network interfaces:
from "ipconfig /all":
Ethernet-Adapter LAN-Verbindung:
Verbindungsspezifisches DNS-Suffix: fritz.box
Beschreibung. . . . . . . . . . . : NVIDIA nForce-Netzwerkcontroller
Physische Adresse . . . . . . . . : 00-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::190f:efaa:1122:19ea%3(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.0.21(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Lease erhalten. . . . . . . . . . : Sonntag, 15. Mai 2016 15:08:56
Lease läuft ab. . . . . . . . . . : Freitag, 27. Mai 2016 20:39:38
Standardgateway . . . . . . . . . : 192.168.0.1
DHCP-Server . . . . . . . . . . . : 192.168.0.1
DHCPv6-IAID . . . . . . . . . . . : 123456789
DHCPv6-Client-DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
DNS-Server . . . . . . . . . . . : 192.168.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter VirtualBox Host-Only Network:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter
Physische Adresse . . . . . . . . : 0a-00-27-00-00-00
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::3883:d613:4325:7239%23(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.56.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 123456789
DHCPv6-Client-DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter VMware Network Adapter VMnet1:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
1
Physische Adresse . . . . . . . . : 00-xx-xx-xx-xx-xx
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::11bf:1254:55fc:b215%34(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.146.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 123456789
DHCPv6-Client-DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Ethernet-Adapter VMware Network Adapter VMnet8:
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet
8
Physische Adresse . . . . . . . . : 00-50-56-C0-00-08
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::7d3b:45c1:5ae7:c409%36(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 192.168.147.1(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.255.0
Standardgateway . . . . . . . . . :
DHCPv6-IAID . . . . . . . . . . . : 123456789
DHCPv6-Client-DUID. . . . . . . . : 00-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx-xx
DNS-Server . . . . . . . . . . . : fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Tunneladapter isatap.{3E9932FB-2FC6-433F-B439-EC4FE3CB33F1}:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Tunneladapter isatap.{7A34D7A2-017E-462E-9968-062C9115542B}:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Tunneladapter isatap.{976BC5B1-6D33-451F-863B-C0F145636BDC}:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix:
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3
Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
Tunneladapter isatap.fritz.box:
Medienstatus. . . . . . . . . . . : Medium getrennt
Verbindungsspezifisches DNS-Suffix: fritz.box
Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #4
Physische Adresse . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP aktiviert. . . . . . . . . . : Nein
Autokonfiguration aktiviert . . . : Ja
from "route print":
===========================================================================
Schnittstellenliste
3...00 xx xx xx xx xx ......NVIDIA nForce-Netzwerkcontroller
23...0a 00 27 00 00 00 ......VirtualBox Host-Only Ethernet Adapter
34...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
36...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
1...........................Software Loopback Interface 1
4...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter
24...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #2
35...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #3
37...00 00 00 00 00 00 00 e0 Microsoft-ISATAP-Adapter #4
===========================================================================
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.0.1 192.168.0.21 10
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 306
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 306
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
192.168.0.0 255.255.255.0 Auf Verbindung 192.168.0.21 266
192.168.0.21 255.255.255.255 Auf Verbindung 192.168.0.21 266
192.168.0.255 255.255.255.255 Auf Verbindung 192.168.0.21 266
192.168.56.0 255.255.255.0 Auf Verbindung 192.168.56.1 266
192.168.56.1 255.255.255.255 Auf Verbindung 192.168.56.1 266
192.168.56.255 255.255.255.255 Auf Verbindung 192.168.56.1 266
192.168.146.0 255.255.255.0 Auf Verbindung 192.168.146.1 276
192.168.146.1 255.255.255.255 Auf Verbindung 192.168.146.1 276
192.168.146.255 255.255.255.255 Auf Verbindung 192.168.146.1 276
192.168.147.0 255.255.255.0 Auf Verbindung 192.168.147.1 276
192.168.147.1 255.255.255.255 Auf Verbindung 192.168.147.1 276
192.168.147.255 255.255.255.255 Auf Verbindung 192.168.147.1 276
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 306
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.56.1 266
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.0.21 266
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.146.1 276
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.147.1 276
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 306
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.56.1 266
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.0.21 266
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.146.1 276
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.147.1 276
===========================================================================
Ständige Routen:
Keine
The network he is using (=has access to the KNX routing/tunneling interface) is the "NVIDIA nForce-Netzwerkcontroller" with 192.168.0.x IP address range.
If I check the routing table for 224-Multicast addresses, I see that
a) 192.168.56.1 and 192.168.0.21 have the same metric: 266
b) 192.168.56.1 is listed BEFORE the correct network 192.168.0.21
Investigation is still in progress, but my current guess is: calimero is using - due to the same metrik - the 192.168.56.1 network interface instead of 192.168.0.21.
Question is:
- Is there a way to tell calimero which networkinterface is the rigth one?
- Is calimero able to detect the right networkinterface automatically?
- Or is this in any case a weird setup and user has to fix the metric by himself?!
KNXTimeoutExceptions when connected by TUNNELING
Hello @bmalinowsky,
dispatching a new state (using Puschbutton, as you described here ) throws KNXTimeoutExceptions when connected by TUNNELING:
tuwien.auto.calimero.exception.KNXTimeoutException: no confirmation reply received for L-Data.req from 1.1.0 to 1/1/10, low priority hop count 6 repeat tpdu 00 81
at tuwien.auto.calimero.knxnetip.ClientConnection.doExtraBlockingModes(ClientConnection.java:236)
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:269)
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.send(KNXnetIPTunnel.java:149)
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:263)
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:304)
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:240)
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:466)
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.write(ProcessCommunicatorImpl.java:262)
at intro.PushButtonActuator2$1.run(PushButtonActuator2.java:327)
at java.util.TimerThread.mainLoop(Timer.java:555)
at java.util.TimerThread.run(Timer.java:505)
By default ROUTER connections never confirm, there fore it is only an issue for TUNNELING.
Only can understand half the requirements from code and this discussion.
Should I ignore the KNXTimeoutExceptions or is there a way to get the confirmations?
Thank you in advance.
Helmut
Hanging EventNotifier Threads
The EventNotifier class introduces hanging threads on connection shutdown, when the ConnectionBase method fireConnectionClosed calls the listeners. Due the EventNotifier implementing one, it's connectionClosed method gets called, which should quit the EventNotifier Thread. The quit method therefore calls interrupt on the Thread and joins on it to wait for it's shutdown. If the EventNotifier, which runs in an endless loop, however isn't in the wait method due to no events in need of processing, the interrupt will only set a interrupt flag instead of throwing an InterruptedException (see reference). This will prevent breaking the loop, procession of the queued events and inenvitiabilly the shutdown of the EventNotifier Thread. Due to used references the garbage collector won't release ressources in the following.
Possible Fix:
Before entering the wait method on the events ArrayDeque an check for the interrupted flag in addition to the empty check could reduce the probability to fail.
Please let me know if further informations are needed or how i can help.
Greetings,
Marcel
How to do a PropertyRead (or even MemWrite)? (not necessarily knc spec conform)
Hi there,
I'm trying to extend an existing KNX Library for arduino microcontroller to be able to read/write properties and read/write memory on the arduino, using KNX and Calimero.
One thing upfront: Is must not necessarily be knx-spec-conform. The important point is: it must just work somehow ;-)
So, what I'm trying to do is the following:
Using calimero with a KNX IP Router to read property of arduino knx device with individual address 1.1.251.
public static void main(String[] args) throws KNXException, InterruptedException, UnknownHostException {
InetAddress hostadr = InetAddress.getByName("224.0.23.12");
int port = 3671;
// setup knx connection
KNXNetworkLinkIP netlink = new KNXNetworkLinkIP(KNXNetworkLinkIP.ROUTING, null, new InetSocketAddress(hostadr, port), false, new TPSettings(false));
netlink.getKNXMedium().setDeviceAddress(new IndividualAddress("1.1.250"));
ManagementProceduresImpl mp = new ManagementProceduresImpl(netlink);
ManagementClientImpl mci = new ManagementClientImpl(netlink);
IndividualAddress device = new IndividualAddress("1.1.251");
byte[] readProperty = mci.readProperty(mci.createDestination(device, true), 0 /* obj-index */, 56 /* prop-id */, 1 /* start */, 1 /* elements*/);
System.out.println("prop: "+Integer.toHexString(readProperty[0]));
}
I already setup the arduino so that it responds with a propertyread-answer. But calimero does not recognise it. So i stepped through the calimero code to get an idea what is missing from arduino code and stumbled on something I don't understand:
While the main-thread is busy with sending the T_CONNECT_REQ_PDU (which, according to calimero code does not need to be ack'ed due to routing mode), the connect from calimero 1.1.250 to arduino 1.1.251 is received on calimero on "Link notifier" thread, which does send's a "disconnect" to the source, means: Calimero sends a disconnect three times to itself ...???!
... while arduino is answering the propertyread-request.
So my questions are:
- Why is calimero doing a disconnect? In source (2.2.1-beta) TransportLayerImpl I found at line 478:
// don't allow (client side)
if (d.getState() == Destination.DISCONNECTED)
sendDisconnect(sender);
What does this mean? Dont allow client side?
Is this a kind of bug?
- Is calimero able to do property read/write as well as mem read/write in such a way (without too much code-overhead)?
- If question nr.2 can be answered with "yes": How should a really simple code-snippet look like? Keep in mind: Is must not be knx-spec-conform. It's sufficient if the arduino can be programmed with a special-calimero-powered-tool.
- If question nr.2 can be answered with "yes": Do you already see something missing from arduino side? any ACK message? Something else?
Or do you see something else that hinders calimero from getting the response properly?
It's really hard for me to get through all the documents and find the correct workflow... So I appreciate any hint on what else is missing.
br,
Alex
1 byte datapoint read
Hello,
I asked some questions concerning datapoints reading in some previous issues, but I still encounter some problems.. ;\
The exception I get when I call readControl is "APDU response length 3 bytes, expected 2 to 2".
And it's weird.. because in the knx control panel (the one where I can create and access objects), my object appears to be "1 byte unsigned integer".
DPTXlatorString: accepts wrong count of KNX raw bytes
According to spec the length of this DPT is fixed to 14 bytes. Calimero lib isn't checking this correctly in DPTXlatorString. Calimero accepts any byte array larger or equal to 14 bytes without error. As a result: anything less then 14 bytes and above a multiple of 14 bytes will be accepted but cutoff. Even for the failed checks (less then 14 bytes) calimero is not throwing an exception but is logging an error which we cannot check for in the code using the translator.
Examples: {0x61, 0x61} => "". Fifteen bytes of 0x61 lead to a string of fourteen "a".
KNX binding fails on sending PercentType to DPT 5.001
Tunneling connection not possible if working with multiple networkinterfaces
I possibly found another issue, that is possibly caused by the same trap as issue #36 :
One of our users is has configured our application to use an KNX IP Interface, so KNX IP Tunneling...
The application tries to connect, but fails with:
Caused by: tuwien.auto.calimero.exception.KNXTimeoutException: timeout connecting to control endpoint KNX-IPIF-800653.fritz.box/192.168.188.56:3671
at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:188)
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.(KNXnetIPTunnel.java:131)
at tuwien.auto.calimero.link.KNXNetworkLinkIP.(KNXNetworkLinkIP.java:142)
at tuwien.auto.calimero.link.KNXNetworkLinkIP.(KNXNetworkLinkIP.java:180)
at de.root1.slicknx.Knx.(Knx.java:301)
... 5 more
I had a look at the code and found this:
The first UDP packet to connect to the KNX IP Tunneling Interface, is sent here:
But the "answer-receiver" is started a few lines later:
So, I guess there's also a gap where an answer might get lost, due to the not-yet started receiver.
I asked the user to capture with wireshark to see if there is an response to the connect datagram.
The weird thing is: If he's changing the network interface metric from "auto" to "1", all is working well...?!
After changing the metrik to 1, the routing table looks like:
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.188.1 192.168.188.28 1 <--------- CHANGED METRIC TO 1
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
169.254.0.0 255.255.0.0 Auf Verbindung 169.254.152.163 281
169.254.152.163 255.255.255.255 Auf Verbindung 169.254.152.163 281
169.254.255.255 255.255.255.255 Auf Verbindung 169.254.152.163 281
192.168.2.0 255.255.255.0 Auf Verbindung 192.168.2.1 291
192.168.2.1 255.255.255.255 Auf Verbindung 192.168.2.1 291
192.168.2.255 255.255.255.255 Auf Verbindung 192.168.2.1 291
192.168.56.0 255.255.255.0 Auf Verbindung 192.168.56.1 281
192.168.56.1 255.255.255.255 Auf Verbindung 192.168.56.1 281
192.168.56.255 255.255.255.255 Auf Verbindung 192.168.56.1 281
192.168.78.0 255.255.255.0 Auf Verbindung 192.168.78.1 291
192.168.78.1 255.255.255.255 Auf Verbindung 192.168.78.1 291
192.168.78.255 255.255.255.255 Auf Verbindung 192.168.78.1 291
192.168.188.0 255.255.255.0 Auf Verbindung 192.168.188.28 257 <----- DEFAULT ROUTE TO LAN
192.168.188.28 255.255.255.255 Auf Verbindung 192.168.188.28 257
192.168.188.255 255.255.255.255 Auf Verbindung 192.168.188.28 257
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.188.28 257
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.56.1 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.78.1 291
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.2.1 291
224.0.0.0 240.0.0.0 Auf Verbindung 169.254.152.163 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.188.28 257
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.56.1 281
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.78.1 291
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.2.1 291
255.255.255.255 255.255.255.255 Auf Verbindung 169.254.152.163 281
===========================================================================
And this works quite well. Calimero is able to connect and KNX telegrams can be sent and received.
With the original "auto" metric, it's not working and giving the timeout error:
IPv4-Routentabelle
===========================================================================
Aktive Routen:
Netzwerkziel Netzwerkmaske Gateway Schnittstelle Metrik
0.0.0.0 0.0.0.0 192.168.188.1 192.168.188.28 25 <--------- USING WINDOWS AUTO METRIC
127.0.0.0 255.0.0.0 Auf Verbindung 127.0.0.1 331
127.0.0.1 255.255.255.255 Auf Verbindung 127.0.0.1 331
127.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
169.254.0.0 255.255.0.0 Auf Verbindung 169.254.152.163 281
169.254.152.163 255.255.255.255 Auf Verbindung 169.254.152.163 281
169.254.255.255 255.255.255.255 Auf Verbindung 169.254.152.163 281
192.168.2.0 255.255.255.0 Auf Verbindung 192.168.2.1 291
192.168.2.1 255.255.255.255 Auf Verbindung 192.168.2.1 291
192.168.2.255 255.255.255.255 Auf Verbindung 192.168.2.1 291
192.168.56.0 255.255.255.0 Auf Verbindung 192.168.56.1 281
192.168.56.1 255.255.255.255 Auf Verbindung 192.168.56.1 281
192.168.56.255 255.255.255.255 Auf Verbindung 192.168.56.1 281
192.168.78.0 255.255.255.0 Auf Verbindung 192.168.78.1 291
192.168.78.1 255.255.255.255 Auf Verbindung 192.168.78.1 291
192.168.78.255 255.255.255.255 Auf Verbindung 192.168.78.1 291
192.168.188.0 255.255.255.0 Auf Verbindung 192.168.188.28 281 <----- DEFAULT ROUTE TO LAN
192.168.188.28 255.255.255.255 Auf Verbindung 192.168.188.28 281
192.168.188.255 255.255.255.255 Auf Verbindung 192.168.188.28 281
224.0.0.0 240.0.0.0 Auf Verbindung 127.0.0.1 331
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.188.28 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.56.1 281
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.78.1 291
224.0.0.0 240.0.0.0 Auf Verbindung 192.168.2.1 291
224.0.0.0 240.0.0.0 Auf Verbindung 169.254.152.163 281
255.255.255.255 255.255.255.255 Auf Verbindung 127.0.0.1 331
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.188.28 281
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.56.1 281
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.78.1 291
255.255.255.255 255.255.255.255 Auf Verbindung 192.168.2.1 291
255.255.255.255 255.255.255.255 Auf Verbindung 169.254.152.163 281
===========================================================================
I'm confused ...
- Why is the receiver started AFTER the datagram has been sent?! --> GAP?
- Why does changing the metric to 1 help? java detects the correct interface by the target IP ...
Of course, disabling all the other network interfaces (vpn, vmware, ...) also helps, but changing the metric or disabling network interfaces is not that user friendly...
Would be great if someone could give me a hint.
KNXNetworkLinkIP leaks threads if it cannot connect
The KNXNetworkLinkIP class leaks threads in case it cannot connect:
The corresponding stacktrace:
16:03:31.705 ERROR tuwien.auto.calimero[:46] - KNXnet/IP Tunneling 10.42.0.13:3671: communication failure on connect
java.net.BindException: Can't assign requested address (Bind failed)
at java.net.PlainDatagramSocketImpl.bind0(Native Method)
at java.net.AbstractPlainDatagramSocketImpl.bind(AbstractPlainDatagramSocketImpl.java:93)
at java.net.DatagramSocket.bind(DatagramSocket.java:392)
at java.net.DatagramSocket.<init>(DatagramSocket.java:242)
at tuwien.auto.calimero.knxnetip.ClientConnection.connect(ClientConnection.java:150)
at tuwien.auto.calimero.knxnetip.KNXnetIPTunnel.<init>(KNXnetIPTunnel.java:131)
at tuwien.auto.calimero.link.KNXNetworkLinkIP.<init>(KNXNetworkLinkIP.java:142)
...
According to what I understood, the super() constructor already spawns the EventNotifier thread and when establishing the KNXnetIPConnection fails down the road, it misses to close the notifier thread.
I observed this behavior in calimero-core 2.3, but if I'm not mistaken it hasn't change in the current master branch.
dpt 229.001 isn't supported
Hello,
I'm trying to work with an energy-meter. It uses the DPT 229.001
This dpt seems to be quite new (2014).
Informations about this DPT can be found in the PDF below, page 75 :
pdf
Is there a way to deal with this DPT for now?
Thanks,
Pierre
ManagementClient.readMemory : 4 attempts, failure, success on next attempt
@bmalinowsky I have the following weird behaviour on the KNX bus when trying to read memory locations from devices. I am using a TUNNEL setup, connection-oriented Destinations. The behaviour is the same for all devices, all memory locations. There is one call made to readMemory() in a loop, but loops until there is no exception thrown and the number of byte[] read is meaningful.
This is part of a little routine where I read out the PID.TABLE_REFERENCE of the Address Table Object Index and then use the returned data to read out the # addresses, the Ind. Address and all the Group Addresses used by the KNX Actor.
It is a bit a lengthy log, but you can see that 4 attempts are made to read a memory location, then it fails with a "send data connected failed", but it works straight away on attempt 1 in the next cycle. Does this indicate timing issues at the end of the KNX actor, or on the bus itself?
2016-04-21 09:51:06.559 [DEBUG] [.k.h.KNXBridgeBaseThingHandler:1070 ] - Trying to read 2 bytes at memory location 16387 for 1.1.11
2016-04-21 09:51:06.559 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:06.559 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 155, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 9b 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:06.559 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: sending data connected to 1.1.11, attempt 1
2016-04-21 09:51:06.559 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:06.560 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, low priority hop count 6 repeat tpdu 46 02 40 03
2016-04-21 09:51:06.575 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 240
2016-04-21 09:51:06.575 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.594 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 241
2016-04-21 09:51:06.594 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.594 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:06.595 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: send disconnect to 1.1.11
2016-04-21 09:51:06.595 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:06.595 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 156, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 17 04 26 9c 00 11 00 bc 60 10 ff 11 0b 03 46 02 40 03
2016-04-21 09:51:06.596 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:06.618 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 242
2016-04-21 09:51:06.619 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.619 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:06.619 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 157, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 9d 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:06.638 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 243
2016-04-21 09:51:06.638 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.638 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:06.639 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: send disconnect to 1.1.11
2016-04-21 09:51:06.639 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:06.639 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:06.639 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 158, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 9e 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:06.659 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 244
2016-04-21 09:51:06.659 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.660 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:06.660 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: send disconnect to 1.1.11
2016-04-21 09:51:06.660 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:06.660 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:06.660 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 159, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 9f 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:06.679 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 245
2016-04-21 09:51:06.679 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.679 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:06.680 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: send disconnect to 1.1.11
2016-04-21 09:51:06.680 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:06.680 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:06.680 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 160, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 a0 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:06.700 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 246
2016-04-21 09:51:06.700 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.700 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:06.701 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: send disconnect to 1.1.11
2016-04-21 09:51:06.701 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:06.701 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:06.701 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 161, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 a1 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:06.721 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 247
2016-04-21 09:51:06.722 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.722 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:06.722 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: send disconnect to 1.1.11
2016-04-21 09:51:06.722 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:06.722 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:06.722 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 162, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 a2 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:06.742 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 248
2016-04-21 09:51:06.742 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:06.742 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:08.220 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.4.11
2016-04-21 09:51:08.223 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.3.102
2016-04-21 09:51:09.619 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: sending data connected to 1.1.11, attempt 2
2016-04-21 09:51:09.619 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:09.619 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, low priority hop count 6 repeat tpdu 46 02 40 03
2016-04-21 09:51:09.620 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 163, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 17 04 26 a3 00 11 00 bc 60 10 ff 11 0b 03 46 02 40 03
2016-04-21 09:51:09.622 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.51
2016-04-21 09:51:09.625 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.51
2016-04-21 09:51:09.646 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 253
2016-04-21 09:51:09.646 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:09.647 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:10.358 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.23
2016-04-21 09:51:10.374 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.23
2016-04-21 09:51:10.437 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.23
2016-04-21 09:51:10.985 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.15
2016-04-21 09:51:10.989 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.13
2016-04-21 09:51:11.185 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.27
2016-04-21 09:51:11.239 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.27
2016-04-21 09:51:12.213 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.14
2016-04-21 09:51:12.217 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.12
2016-04-21 09:51:12.229 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.26
2016-04-21 09:51:12.646 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: sending data connected to 1.1.11, attempt 3
2016-04-21 09:51:12.647 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:12.647 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, low priority hop count 6 repeat tpdu 46 02 40 03
2016-04-21 09:51:12.647 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 164, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 17 04 26 a4 00 11 00 bc 60 10 ff 11 0b 03 46 02 40 03
2016-04-21 09:51:12.672 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 8
2016-04-21 09:51:12.673 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:12.673 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:13.442 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.26
2016-04-21 09:51:13.446 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.26
2016-04-21 09:51:13.450 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.26
2016-04-21 09:51:15.678 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: sending data connected to 1.1.11, attempt 4
2016-04-21 09:51:15.678 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:15.678 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, low priority hop count 6 repeat tpdu 46 02 40 03
2016-04-21 09:51:15.679 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 165, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 17 04 26 a5 00 11 00 bc 60 10 ff 11 0b 03 46 02 40 03
2016-04-21 09:51:15.682 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.101
2016-04-21 09:51:15.707 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 13
2016-04-21 09:51:15.707 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:15.707 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:16.808 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.152
2016-04-21 09:51:16.812 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.152
2016-04-21 09:51:16.834 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.152
2016-04-21 09:51:16.869 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.152
2016-04-21 09:51:16.904 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.152
2016-04-21 09:51:16.966 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.151
2016-04-21 09:51:17.007 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.151
2016-04-21 09:51:17.046 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.151
2016-04-21 09:51:17.191 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.151
2016-04-21 09:51:17.226 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.151
2016-04-21 09:51:17.260 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.151
2016-04-21 09:51:17.305 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.151
2016-04-21 09:51:17.345 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.2.151
2016-04-21 09:51:18.051 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.151
2016-04-21 09:51:18.054 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.151
2016-04-21 09:51:18.358 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.24
2016-04-21 09:51:18.393 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.24
2016-04-21 09:51:18.456 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.24
2016-04-21 09:51:18.570 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.55
2016-04-21 09:51:18.620 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.55
2016-04-21 09:51:18.707 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.708 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.708 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 166, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 a6 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:18.728 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 34
2016-04-21 09:51:18.728 [ERROR] [.k.h.KNXBridgeBaseThingHandler:1092 ] - An exception occurred while trying to read the memory for '1.1.11' : send data connected failed
2016-04-21 09:51:18.728 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.728 [DEBUG] [.k.h.KNXBridgeBaseThingHandler:1070 ] - Trying to read 2 bytes at memory location 16387 for 1.1.11
2016-04-21 09:51:18.728 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.728 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: disconnected from 1.1.11
2016-04-21 09:51:18.728 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.729 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 80
2016-04-21 09:51:18.729 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 167, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 a7 00 11 00 b0 60 10 ff 11 0b 00 80
2016-04-21 09:51:18.748 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 35
2016-04-21 09:51:18.749 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.749 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.749 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: connected with 1.1.11
2016-04-21 09:51:18.749 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: sending data connected to 1.1.11, attempt 1
2016-04-21 09:51:18.749 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.750 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, low priority hop count 6 repeat tpdu 42 02 40 03
2016-04-21 09:51:18.750 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 168, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 17 04 26 a8 00 11 00 bc 60 10 ff 11 0b 03 42 02 40 03
2016-04-21 09:51:18.774 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 36
2016-04-21 09:51:18.774 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.774 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.837 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.11
2016-04-21 09:51:18.837 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.838 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.838 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 169, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 a9 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:18.858 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 38
2016-04-21 09:51:18.858 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.858 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.859 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.859 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: positive ack by 1.1.11
2016-04-21 09:51:18.859 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.859 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 170, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 aa 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:18.884 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: indication from 1.1.11
2016-04-21 09:51:18.903 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 40
2016-04-21 09:51:18.904 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.904 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.904 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.904 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.905 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 171, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 ab 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:18.924 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 41
2016-04-21 09:51:18.925 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.925 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.925 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.925 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.925 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 172, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 ac 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:18.946 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 42
2016-04-21 09:51:18.946 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.946 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.946 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.946 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.946 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 173, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 ad 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:18.967 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 43
2016-04-21 09:51:18.967 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.967 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.968 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.968 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.968 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 174, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 ae 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:18.986 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 44
2016-04-21 09:51:18.987 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:18.987 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:18.987 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:18.987 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:18.987 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 175, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 af 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:19.006 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 45
2016-04-21 09:51:19.007 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:19.007 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:19.008 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:19.008 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:19.008 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 176, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 b0 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:19.026 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 46
2016-04-21 09:51:19.026 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:19.027 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:19.027 [DEBUG] [tuwien.auto.calimero :45 ] - TL 192.168.0.10:3671: send disconnect to 1.1.11
2016-04-21 09:51:19.027 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11, wait for confirmation
2016-04-21 09:51:19.027 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu 81
2016-04-21 09:51:19.027 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 177, wait for cEMI.con, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 b1 00 11 00 b0 60 10 ff 11 0b 00 81
2016-04-21 09:51:19.046 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: received cEMI L-Data.con with req 47
2016-04-21 09:51:19.046 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: confirmation of 1.1.11
2016-04-21 09:51:19.046 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:19.046 [INFO ] [tuwien.auto.calimero :43 ] - calimero.link.192.168.0.10:3671: send message to 1.1.11
2016-04-21 09:51:19.046 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: cEMI L-Data.req from 1.0.255 to 1.1.11, system priority hop count 6 repeat tpdu c2
2016-04-21 09:51:19.046 [DEBUG] [tuwien.auto.calimero :45 ] - KNXnet/IP Tunneling 192.168.0.10:3671: sending cEMI frame seq 178, wait for ack, attempt 1 (channel 38) 06 10 04 20 00 14 04 26 b2 00 11 00 b0 60 10 ff 11 0b 00 c2
2016-04-21 09:51:19.049 [DEBUG] [tuwien.auto.calimero :45 ] - calimero.link.192.168.0.10:3671: send to 1.1.11 succeeded
2016-04-21 09:51:19.050 [DEBUG] [.k.h.KNXBridgeBaseThingHandler:1081 ] - Reading 2 bytes at memory location 16387 for 1.1.11 yields 2 bytes
calimero dimming read and write
Hello,
I have 2 problems:
- Reading switch (1bit boolean) and dimming (1byte unsigned int) datapoints.
In order to do that, I used these 2 functions below, but "catch" occurs.
Below you can see the objects I created and the logs read attempts.
Is it about bad objects configuration or am I using wrong the library methods ?
- I have a method that gets triggered whenever knx connection gets lost:
@OverRide
public void linkClosed(CloseEvent e) { //code to execute }
But I tried the following scenario: turned off mobile data and this function gets triggered after 30-45 seconds after losing the internet connection.
You told me in another issue post that what I'm seeking for is an idle state trigger over the knxlink.. I failed finding the proper function that takes care of that, can you give me a concrete code example, please ?
I'd really appreciate your help !
Calimero does not check for bundleresource protocol (equinox/osgi)
Hallo,
i've had add to current Calimero core snapshot (2.4-SNAPSHOT) to openhab knx binding and be can an excetion:
java.nio.file.ProviderNotFoundException: Provider "bundleresource" not found
at java.nio.file.FileSystems.newFileSystem(Unknown Source) ~[na:1.8.0_131]
at java.nio.file.FileSystems.newFileSystem(Unknown Source) ~[na:1.8.0_131]
at tuwien.auto.calimero.dptxlator.TranslatorTypes.loadTranslators(TranslatorTypes.java:369) ~[calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.dptxlator.TranslatorTypes.<clinit>(TranslatorTypes.java:347) ~[calimero-core-2.4-SNAPSHOT.jar:na]
at org.openhab.binding.knx.internal.dpt.KNXCoreTypeMapper.toType(KNXCoreTypeMapper.java:326) [bundlefile:na]
at org.openhab.binding.knx.internal.bus.KNXBinding.getType(KNXBinding.java:455) [bundlefile:na]
at org.openhab.binding.knx.internal.bus.KNXBinding.readFromKNX(KNXBinding.java:225) [bundlefile:na]
at org.openhab.binding.knx.internal.bus.KNXBinding.groupWrite(KNXBinding.java:186) [bundlefile:na]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl$NLListener.lambda$fireGroupReadWrite$2(ProcessCommunicatorImpl.java:128) [calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:129) ~[calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl$NLListener.fireGroupReadWrite(ProcessCommunicatorImpl.java:129) [calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl$NLListener.indication(ProcessCommunicatorImpl.java:111) [calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.link.AbstractLink$LinkNotifier.lambda$frameReceived$0(AbstractLink.java:144) ~[calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.internal.EventListeners.fire(EventListeners.java:129) ~[calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.link.EventNotifier.fire(EventNotifier.java:165) ~[calimero-core-2.4-SNAPSHOT.jar:na]
at tuwien.auto.calimero.link.EventNotifier.run(EventNotifier.java:102) ~[calimero-core-2.4-SNAPSHOT.jar:na]
To fix the exception, modify the TranslatorTypes class.
Pathset:
--- src/tuwien/auto/calimero/dptxlator/TranslatorTypes.java (revision e5481989b6ef199a128e5e19681d05dc311625fc)
+++ src/tuwien/auto/calimero/dptxlator/TranslatorTypes.java (revision )
@@ -368,7 +368,8 @@
loadTranslators(inPackage, fs.provider().getPath(uri));
}
catch (final Exception ex) {
- if (!"bundle".equals(uri.getScheme()))
+
+ if (!"bundle".equals(uri.getScheme()) && ! "bundleresource".equals(uri.getScheme()))
throw ex;
DPTXlator.logger.info("using osgi bundle wiring for {}", uri);
Device discovery not reliable?!
Hi,
I'm using 2.3-beta and face the following problem when trying to discover KNX interface devices:
The result is not deterministic: Sometimes I find my routing and tunneling device, sometimes not. I then just need to repeat the procedure a few times, and device is again detected...
here's the related code-snippet I'm using:
List<KnxInterfaceDevice> foundDevices = new ArrayList<>(); // List of detected devices. KnxInterface Device is a simple container object that holds the relevant information for my application to setup the correct KNX connection
try {
Enumeration<NetworkInterface> networkInterfaces = NetworkInterface.getNetworkInterfaces();
// addresses to scan
int count = 0;
if (progress != null) {
// gathering count data
while (networkInterfaces.hasMoreElements()) {
NetworkInterface ni = networkInterfaces.nextElement();
if (ni.isLoopback() || !ni.isUp()) {
continue;
}
for (InterfaceAddress iaddr : ni.getInterfaceAddresses()) {
if (iaddr.getAddress() instanceof Inet6Address) {
continue;
}
count++;
}
}
networkInterfaces = NetworkInterface.getNetworkInterfaces();
}
int i = 0;
while (networkInterfaces.hasMoreElements()) {
NetworkInterface ni = networkInterfaces.nextElement();
if (ni.isLoopback() || !ni.isUp()) {
continue;
}
log.debug("Found network interface: " + ni.getName() + "/" + ni.getDisplayName() + "/" + ni.getInterfaceAddresses());
try {
for (InterfaceAddress iaddr : ni.getInterfaceAddresses()) {
if (iaddr.getAddress() instanceof Inet6Address) {
continue;
}
log.debug("Discovering on " + ni.getName() + "@" + iaddr.getAddress());
Discoverer discoverer = new Discoverer(iaddr.getAddress(), 0, false, false);
if (progress != null) {
i++;
progress.onProgress(i, count, ni, iaddr.getAddress());
}
discoverer.startSearch(ni, timeout, true);
SearchResponse[] result = discoverer.getSearchResponses();
for (SearchResponse sr : result) {
ServiceFamiliesDIB serviceFamilies = sr.getServiceFamilies();
int[] familyIds = serviceFamilies.getFamilyIds();
for (int n = 0; n < familyIds.length; n++) {
int id = familyIds[n];
KnxInterfaceDevice foundDevice = null;
switch (id) {
case ServiceFamiliesDIB.ROUTING:
foundDevice = new KnxRoutingDevice(ni, sr);
break;
case ServiceFamiliesDIB.TUNNELING:
foundDevice = new KnxTunnelingDevice(ni, sr);
break;
default:
log.warn("Unsupported device family: {}", serviceFamilies.getFamilyName(id));
}
if (foundDevice != null) {
log.debug("Found: {}", foundDevice);
foundDevices.add(foundDevice);
}
}
}
discoverer.clearSearchResponses();
}
} catch (Exception ex) {
ex.printStackTrace();
}
}
} catch (SocketException ex) {
ex.printStackTrace();
}Some words on the implementation:
When working with multiple network interfaces on a single machine, I have to know on which network interface the KNX IP Router is running. So I first get all related network interfaces and then run a discovery on each of them. It makes no difference if I use a timeout of 1sec, 5sec or 15sec.
I personally faced this issue in Debian Testing AMD64, but some other people faced this on Win7 as well.
I have no firewall running. The PC is connected via LAN to a switch, where also the MDT IP Router is connected to (no WiFi or Fritzbox inbetween).
Any ideas what's wrong?!
the “win7_OrLater” static field issue in Discoverer class
I Think "win7_OrLater" should assign on this way
win7_OrLater = Double.parseDouble(ver) >= 6.1
Because the win7 kernel version is 6.1 .
Connecting with multicast interface requests to the bus are always flaged with repeated=true
Hello @bmalinowsky,
when connecting calimero by multicast interface to a KNX bus, all requests (respond or write) coming from calimero have set the "RepeatedFlag" flag to true. Debugged with ETS5.
This is definitively not correct, because it is not a repeated!
It also has the side-effect, that repeated request without previous external bus transactions from other devices, can not be answered by calimero.
It seams with a connection by TUNNEL, requests are correctly flagged.
I connected with several calimero tools and examples (ProcComm and PushButtonActuator etc.) same effect. I only can prevent it hardcoded over CEMILData.setRepeat().
I do not understand all backgrounds to fix the error in calimero.
Thank you in advance.
Helmut
DPTXlator4ByteFloat getValues() uses different locales based on value
DPTXlator4ByteFloat is using different locales within makeString() method. If the float is less then 100000 then String.valueOf() is used, which is actually Float.toString(). This is a non-localized method. If the float is larger or equal 100000 then DecimalFormat("0.#####E0").format() is used. DecimalFormat uses the default locale.
Since DPTXlator2ByteFloat is also using non-localized output: I'd like to suggest to change the output to non-localized.
Can write data, but can't read data
I've tried out today this example from calimero-introduction-repo, version 2.4:
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.UnknownHostException;
import tuwien.auto.calimero.GroupAddress;
import tuwien.auto.calimero.KNXException;
import tuwien.auto.calimero.link.KNXNetworkLink;
import tuwien.auto.calimero.link.KNXNetworkLinkIP;
import tuwien.auto.calimero.link.medium.TPSettings;
import tuwien.auto.calimero.process.ProcessCommunicator;
import tuwien.auto.calimero.process.ProcessCommunicatorImpl;
/**
* Example of Calimero process communication, we read (and write) a boolean datapoint in the KNX network. By default,
* this example will not change any datapoint value in the network.
*/
public class ProcessCommunication {
// Address of your KNXnet/IP server. Replace the IP host or address as necessary.
private static final String remoteHost = "192.168.1.84";
// We will read a boolean from the KNX datapoint with this group address, replace the address as necessary.
// Make sure this datapoint exists, otherwise you will get a read timeout!
private static final String group = "0/5/6";
public static void main(final String[] args) {
final InetSocketAddress remote = new InetSocketAddress(remoteHost, 3671);
// Create our network link, and pass it to a process communicator
try (KNXNetworkLink knxLink = KNXNetworkLinkIP.newTunnelingLink(null, remote, false, TPSettings.TP1);
ProcessCommunicator pc = new ProcessCommunicatorImpl(knxLink)) {
System.out.println("read boolean value from datapoint " + group);
final boolean value = pc.readBool(new GroupAddress(group));
System.out.println("datapoint " + group + " value = " + value);
// final boolean value = true;
// Uncomment the next line, if you want to write back the same value to the KNX network
// pc.write(new GroupAddress(group), value);
} catch (KNXException | InterruptedException e) {
System.out.println("Error accessing KNX datapoint: " + e.getMessage());
}
}
}This code works fine when I'm only writing to the KNX system: pc.write(new GroupAddress(group), value), but when I try to read a value: pc.readBool(new GroupAddress(group)) from the same group address, I get a read timeout exception.
I've also searched through other closed issues (#41, #21), but nothing from there seems to work.
I'm building an running my code from Mac OS 10.13.3 through IntelIJ IDEA.
My KNX system is available through an IP-router on a local address.
The datapoint I've tested on is my room's light system.
The discover KNX/IP server example prints this result:
en0 /192.168.1.163 <= 192.168.1.84:3671 (IPv4 UDP) "KNX / IP-Router REG-K"
KNX address 1.1.0
KNX medium TP1
installation 0 - project 0 (ID 0)
routing multicast address 224.0.23.12
MAC address myMacAddress
S/N mySN
Core (v1)
Device Management (v1)
Tunneling (v1)
Routing (v1)
Any suggestions on what I should do?
Thanks!
Please note: I'm new to the whole KNX environment, just started learning about it 2 days ago :D
Any example for Android environment with new library?
Hello all,
Is there any usage of latest calimero-core in an Android project? There are some examples in the history but they are very old and I believe with a much older calimero version. I spent a couple of hours to run it on Android but couldn't manage that. Is there anyone to give advise?
Thank you,
Communication blocked for 255 telegrams once Calimero rcv-seq behind
Communication is blocked for the next 255 telegrams if the Calimero counter somehow is behind the received seq-ctr.
See discussion at: https://sourceforge.net/p/calimero/discussion/485103/thread/7204e4d1/
Getting values from KNX module
Hello
I'm currently working with Calimero (which is pretty useful!) and I've a question about how to get value from a KNX module.
My Weather Station have sensors (temperature, humidity etc.) and I'm now able to ask a value using the librairy :
client (Calimero) --------> KNX module (Weather Station)
client (Calimero)<-------- temperature (p. ex.)
I'd like now to get values in a different way, this one :
client (Calimero)<-------- KNX module (Weather Station)
client (Calimero) --------> temperature (p. ex.)
Description : the Weather Station send to the client the temperature (p. ex.), when the values changes (is it possible, may I set in ETS that I'd like the value when it changes from 0.5°C p. ex. ?)
I also configure the KNX module to send on the bus the value every hour. Is it possible to be notify in Calimero ?
This is kind of a monitoring app.
Thanks in advanced if you have some examples/informations about this problem.
Have a goo day
Android connection error catch
I'm trying to establish a KNX connection using calimero library.
While using a public static void main, it's working just fine (code example below), but I'm having troubles trying to connect in an Android application.
Connection using public static void main (it works):
`public class Main {
private static final String remoteHost = "my_remote_ip_here";
private static final String localHost = "my_local_ip_here";
private static final String group = "0/0/1";
private static final int knxServerPort = KNXnetIPConnection.DEFAULT_PORT;
/**
* @param args
*/
public static void main(final String[] args) {
KNXNetworkLink knxLink = null;
ProcessCommunicator pc = null;
System.out.println("This example shows how to establish a KNX connection "
+ "to a KNXnet/IP server.");
try {
final InetSocketAddress localEP = new InetSocketAddress(
InetAddress.getByName(localHost), 0);
final InetSocketAddress remoteEP = new InetSocketAddress(remoteHost, knxServerPort);
System.out.println("Try connecting to " + remoteHost + " on port " + knxServerPort + "...");
knxLink = new KNXNetworkLinkIP(KNXNetworkLinkIP.TUNNELING, localEP, remoteEP, true,
TPSettings.TP1);
System.out.println("Connection to " + remoteHost + " successfully established");
knxLink.close();
System.out.println("Connection got closed");
}
catch (final KNXException e) {
System.out.println("Error connecting to " + remoteHost + ": " + e.getMessage());
}
catch (final InterruptedException e) {
System.out.println("Connecting to " + remoteHost + " was interrupted, quit");
}
catch (final UnknownHostException e) {
System.out.println("Host resolution for local endpoint " + localHost + " failed");
}
}
}`
Connection in onCreate() (error catch):
`public class MainActivity extends AppCompatActivity {
private static final String remoteHost = "my_remote_ip_here";
private static final String localHost = "my_local_ip_here";
private static final String group = "0/0/1";
private static final int knxServerPort = KNXnetIPConnection.DEFAULT_PORT;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
KNXNetworkLink knxLink = null;
ProcessCommunicator pc = null;
Log.d("asdf", "This example shows how to establish a KNX connection to a KNXnet/IP server.");
try {
final InetSocketAddress localEP = new InetSocketAddress(
InetAddress.getByName(localHost), 0);
final InetSocketAddress remoteEP = new InetSocketAddress(remoteHost, knxServerPort);
Log.d("asdf", "Try connecting to " + remoteHost + " on port " + knxServerPort + "...");
knxLink = new KNXNetworkLinkIP(KNXNetworkLinkIP.TUNNELING, localEP, remoteEP, true, TPSettings.TP1);
Log.d("asdf", "Connection to " + remoteHost + " successfully established");
knxLink.close();
Log.d("asdf", "Connection got closed");
}
catch (final KNXException e) {
Log.d("asdf", "Error connecting to " + remoteHost + ": " + e.getMessage());
}
catch (final InterruptedException e) {
Log.d("asdf", "Connecting to " + remoteHost + " was interrupted, quit");
}
catch (final UnknownHostException e) {
Log.d("asdf", "Host resolution for local endpoint " + localHost + " failed");
}
}
}`
knxLink = new KNXNetworkLinkIP(KNXNetworkLinkIP.TUNNELING, localEP, remoteEP, true,TPSettings.TP1);
After executing this line, error is catched, by the following catch block:
catch (final KNXException e) { Log.d("asdf","Error connecting to " + remoteHost + ": " + e.getMessage()); }
I removed the real IPs in these examples, but everytime I'm trying to connect, I use legit IPs.
I'd appreciate some help. Thank you!
Wrap around of sequence number from 255 to 0 not considered?
I think in KNXnetIPTunnel.java in line 182 it should be
if (seq == getSeqRcv() || ((seq + 1) & 0xFF) == getSeqRcv()) {
instead of
if (seq == getSeqRcv() || seq + 1 == getSeqRcv()) {
LocalEP in case of tunneling: Sense?
Hi there,
struggling (again) with the tunneling mode. It works for windows, but not for linux. I get an IOException telling me that the given argument is invalid. This happens on first UDP datagra sending...
I've broken down the issue to this line:
The local endpoint is used to tell the udp datagram socket where the data to be sent comes from.
On windows it seems that InetAddress.getLocalHost() gives the correct and useable network IP address of the host (not localhost ip), but on linux all of my systems resolve to "myhostname:127.0.1.1:0". And this localhost IP cannot be used as an endpoint (of course...).
It makes no sense for me to change my local name resolution, as other services rely more or less on this kind of localhost IP.
So question is: What sense does it make to tell the operating system which endpoint to use. Why not provide no endpoint at all and let the OS decide?!
library import
Hi there,
I used this library 7 months ago, and I resumed the project (android), but classes are not recognized anymore..
I placed " implementation 'com.github.calimero-project:calimero-core:v2.3' " in my gradle, "maven { url 'https://jitpack.io' } " aswell.
If I'll get through this problem, I'd like to know if there's any way to get notified whenever the knxconnection goes down without running a second thread with a infinite loop in it that checks the connection..
I'd appreciate your help.. :)
Release-Plan?
Hi,
just wanted to ask if there is a kind of release plan?
For now I can work with the 2.3-snapshot, but would be good to know when 2.3 could arrive.
br,
Alex
DPTXlatorDateTime: DST handling problem
DPTXlatorDateTime thwos an KNXFormatException: "differing daylight saving time", when DST field is set in KNX msg.
Problem seems to be in "fromDPTMilliseconds(final int index)", where a Calendar object is cleared and populated with date and time info. Clearing a Calendar object will clear field Calendar.DST_OFFSET. A later comparison in this method will then always fail and hence the exception is thrown.
How to connect to KNX/IP router with desktop application?
Hi, I'm Ana Katarina from Croatia and my task is to make a desktop application that will be able to connect with the KNX / IP router and receive telegram from weather station and save that parameters to database. I'm using Schneider knx router and ETS 3 software. My weather station sends rain as a bit- rain/no rain, temperature, brightness value-lux, is it morning or evening also as bit and wind speed in meters per second.
In my university it's unicast, does that make some difference in code? Because when I was looking for the right code for my project it's mulitcast everywhere.
If I only want to connect to router and receive telegrams from weather station I only need class for connection and class for routing?
DPTXlator2ByteFloat: inaccurate precision
DPTXlator2ByteFloat cannot represent the maximum and minimum values for this type.
Root cause seems to be in private method: fromDPT(). The accuracy when calculating the value is Float but might need to be Double.
The following test cases test the erroneous calculation: 0x7FFF should result in 670760.96 but results in 670760.94 and 0xF800 should result in -671088.64 but results in -671088.6.
ProcessCommunicator.readBool switches light
Hello,
First of all, thanks for the lib, great work !
Im starting a projet and just testing stuff with the API and provided examples.
I have an issue I do not understand... I use processCommunicator.readBool(dpAddress) to get the current state of a switch group address. But when the read is performed, the light switches (off to on or the other way).
I cannot understand why a read changes some value ?!
How can I get the state of GA to initialize the states (get if the light is on or off) ?
Regards,
Eric
Awaiting 2.3 release ...
In reference to issue #28 --> Is there any update on this? Will the release come this year?
Java 9
Can I ask why the library requires Java 9?
I presume that a lot of people will want to incorporate the library into their own applications and creating a dependency on Java 9 will make that much more difficult. (I can't tell you how many complaints I got from people when I dared to try and uplift j2mod to Java 7!!)
Java 8 would seem reasonable but 9 is very new for most industrial vendors.
Datapoint conversion
Hello, i have more a question than an issue.
Is there an easy method or way to convert the data received from my KNX Network to java Types.
To explain this more, i already translated them from hex to a string already my problem is for further use i need strictly boolean vlaues(true/false), since Java isn't able to detect "on"(DPT 1.001) as "true" (for example) i need another way.
Is there an Method implemented already that i didn't find or has someone found a work around or is my bet on creating a mapping?
Greetings,
Daniel
Better using 2.3 Release or current 2.4 master for new Projects
@bmalinowsky, is it foreseeable when version 2.4 reached the beta level? I think about what would be better to use currently, 2.3 Release or current 2.4 master for a new Project.
ProcessCommunicatorImpl: Not able to write a response
I'm using Calimero to adapt a RS485 device to KNX, so that it behaves like a KNX device.
So far, it works. But:
If someone initiates a read-request for a specific group-address the software-device is listening on, calimero is answering the request f.i. by calling ProcessCommunicatorImpl#public void write(GroupAddress, boolean).
This call is delegated to private method write(GroupAddress, Priority, DPTXlator), which invokes
lnk.sendRequestWait(dst, p, createGroupAPDU(GROUP_WRITE, t));So, the write-calls which can be done by ProcessCommunicatorImpl are always of the WRITE. No possibility to send a RESPONSE.
I like to discuss a solution for this. For now, I copy&pasted the complete ProcessCommunicatorImpl class, duplicated the write methods and added a boolean-parameter to each duplicated public-write method: "boolean isResponse", and added "int service" to the private-write method so that in case of "isResponse=true", the service GROUP_RESPONSE is used instead of GROUP_WRITE.
So now i have the option in ProcessCommunicatorImpl to call
write(GroupAddress dst, boolean value) to send a WRITE, or use
write(boolean isResponse, GroupAddress dst, boolean value)and decide whether this is a WRITE or a RESPONSE.
How to you guys think about it?
br,
Alex
calimero 2.4 no LogManager anymore
Hi,
in calimero 2.3, I had to add my own LogAdapter to the LogManager to get logging:
LogManager.getManager().addWriter(null, logAdapter);
Now, in calimero 2.4 there are no LogManager, LogWriter anymore.
Does calimero no longer need a LogAdapter?
Or how should I get logging?
Thank You!
Translator for DPT 22.101
Hi, first of all thanks for the great library.
It seems that DPT 22.101 is currently not supported by Calimero.
The Datapoint is RHCC Status and is described in this document.
Are there any plans to integrate this. Do you have any tips how I could deal with this in the meantime?
Thanks, best regards
Phil
BCU/Tpuart + Calimero = IP Router?
Hi there,
just wondering if it's somehow possible to attach an BCU/TpUart (like Siemens 5WG1 117-2AB11
--> https://www.siemens.be/cmc/upload/cms/docs/sbt/hvac/Brochures_Datasheets_manuals/FR/07_Building_Automation_Desigo/Datasheets/Desigo%20TRA%20-%20GAMMA_TPI_UP117_11_de.pdf) to rs232 /via usb to the PC and use it, together with calimero to get an "knx ip router"...?!
The mentioned BCU is already used in many DIY projects to access the knx bus. But if it's possible to combine it with calimero and get an ip router, this would be great.
The "eibd" from Martin Kögler (https://www.auto.tuwien.ac.at/~mkoegler/index.php/eibd) supports this.
How about calimero?
br,
Alex
Build error on windows: unmappable character for encoding Cp1252
Get this error when build on windows
Task :compileTestJava
\calimero-core\test\tuwien\auto\calimero\dptxlator\DPTXlatorUtf8Test.java:187: error: unmappable character for encoding Cp1252
final String signs = "├å├?├æ├ÿ├¢";
possible sollution: add this to build.gradle
compileJava.options.encoding = 'UTF-8'
compileTestJava.options.encoding = 'UTF-8'
calimero doesn't run on concierge / translator lookup magic
This is meant to be more a question than a real bug report: I noticed that calimero is currently not running on the concierge OSGi framework implementation. To my understanding this is due to a bug in concierge and therefore I created eclipse-archived/concierge#52 there.
Nevertheless, this made me aware of this very hacky place in calimero:
calimero-core/src/tuwien/auto/calimero/dptxlator/TranslatorTypes.java
Lines 357 to 393 in 1a513de
And therefore I'd like to ask whether this reflection-based lookup really is necessary for whatever reason or if it just convenient?
If that was just for convenience, then maybe something like this would still be reasonably feasible?
private static final Map<Integer, MainType> map = Collections.synchronizedMap(new HashMap() {
{
Stream.of(//
DPTXlator1BitControlled.class, //
DPTXlator2ByteFloat.class, //
DPTXlator2ByteUnsigned.class, //
DPTXlator3BitControlled.class, //
DPTXlator4ByteFloat.class, //
DPTXlator4ByteSigned.class, //
DPTXlator4ByteUnsigned.class, //
DPTXlator64BitSigned.class, //
DPTXlator8BitEnum.class, //
DptXlator8BitSet.class, //
DPTXlator8BitSigned.class, //
DPTXlator8BitUnsigned.class, //
DPTXlatorBoolean.class, //
DPTXlatorDate.class, //
DPTXlatorDateTime.class, //
DptXlatorMeteringValue.class, //
DPTXlatorRGB.class, //
DPTXlatorSceneControl.class, //
DPTXlatorSceneNumber.class, //
DPTXlatorString.class, //
DPTXlatorTime.class, //
DPTXlatorUtf8.class //
).forEach(x -> {
try {
Map<String, DPT> dpts = (Map<String, DPT>) x
.getDeclaredMethod("getSubTypesStatic", (Class<?>[]) null).invoke(null, (Object[]) null);
final String id = dpts.values().iterator().next().getID();
final String s = id.substring(0, id.indexOf('.'));
final int mainNumber = Integer.parseInt(s);
String desc = descriptionFor(x) + " (main number " + mainNumber + ")";
put(mainNumber, new MainType(mainNumber, x, desc));
} catch (IllegalAccessException | InvocationTargetException | NoSuchMethodException e) {
// ...
}
});
}
});The manual effort of adding another translator would be limited to a single line, the rest would still be figured out automatically. Just a little less magical.
Reading/writing value from/to a KNX module
Hello !
I'm currently trying to read/write a value from/to a KNX module. I tried to follow the steps from this post (#21) but I've issues because the basic code source has changed (remoteHost isn't anymore a String but a InetAdress per example).
Is it possible to update these parts of the code so I could try to make my application work ?
Thanks a lot and sorry for my bad english :D
remoteHost invalid argument
It gives an error when I give the ip address like the comment.
/**
* Specifies the KNX server, either as host name or IP address,
* used for access to the KNX network. Replace the string with an actual host/address of yours. For example, if you know the IP address
* of your KNXnet/IP server, use something like "192.168.1.20".
*/
private static final String remoteHost = "192.168.100.98";
This example shows how to establish a KNX connection to a KNXnet/IP server.
Try connecting to 192.168.100.98 ...
Error connecting to 192.168.100.98: on connect to /192.168.100.98:3671: Invalid argument (sendto failed)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.