USB-RF Server - No programming possible

[lukasriegel]

Hi I'm currently trying to get started with the calimero-server. What I try to achieve is the following setup: calimero-server with attached USB KNX RF Stick to control some KNX RF actors

The installation and initial setup of calimero-server worked fine - as far as I can judge it until now. When trying to add my devices using ETS I face the following error: "Die Busverbindung KnxIpTunneling : calimero - 192.168.1.106:3671 der Linie 7.1 Linie konnte nicht hergestellt werden. Object reference not set to an instance of an object."

Can someone please support me in getting it up and running? Thanks in advance! server-config.xml.zip ets_project.zip

[calimero-project]

Hi,

your error "Object reference not set to an instance of an object" is a really generic response (from .NET, not ETS). Are you trying to just "add" devices, or actually programming them. For adding devices, no server connection is required at all.

• For completeness, can you post the server-config.xml?
• Does ETS show you some useful info if you do a "Read device info" on the bus tab, with the server address (which should be 7.1.0 in your case)? The server should show the info of your rf stick.
• I assume process communication works (reading/writing a group address)?
• Does the server show any warnings or errors?

[lukasriegel]

Hi, I attached the server-config.xml in the initial entry above. Does ETS show you some useful info if you do a "Read device info" on the bus tab, with the server address 7.1.0? --> Unbekannte BCU Version $2311

The USB Stick is recognized during startup of the server

If I try to program the error immeadiately pops up. No Logs in calimero-server or messages on the bus tab.

[calimero-project]

Thank you for the additional info.

Device descriptor 0x2311 (i.e., BCU Version) is the identifier for "RF USB interface v2", so I am not sure why ETS doesn't recognize that.

Anyway, USB interfaces mostly don't support more than one connection. And that single connection has to have the same address as the usb interface itself. You can try to set reuseCtrlEP="true" as serviceContainer attribute in the server config. This will not use any additional addresses (i.e., the address will always be the same as the usb stick address).

If the the rf stick is sending within a specific domain, you might also try the subnet specific domainAddress attribute. This is a 6 byte hex value, and by default in calimero set to the broadcast domain.

[lukasriegel]

OK I updated the config to the following server-config.xml.zip And tried it with explicitly setting the domain address <knxSubnet type="usb" medium="rf" domainAddress="000000004b01"></knxSubnet> Still the same result. This is what I get during startup And when trying to read the device info

Any further ideas?

(not sure if relevant for this problem: I'm using the current master branch)

[calimero-project]

I see now from your second post, that you have the busmonitor running, while trying to establish a connection for programming. That doesn't work. Busmonitoring allows only 1 connection, that is also the error message. Stop busmonitoring while programming.

The server communication looks fine, and reading device info in itself is not important (although I'm curious about the unbekannte bcu version fehler).

In your latest screenshot, the server is still using additional addresses (if there is a file "knx-server-ios.xml" delete that, between restart).

[lukasriegel]

Right - seems I forgot to stop and close the busmonitor.

Regarding the additional addresses. Not sure if I missed something there - maybe forgot to save or restart calimero.. Now the logs look the following

Still no chance to program. Maybe I'm missing some simple piece as I'm new to this topic... Can you maybe share a minimum working example configuration how ETS can work with calimero with a RF USB stick?

[calimero-project]

So you're back to the error "Object reference not set to an instance of an object", right?

• the thing is, the connection setup works fine, as can be seen from the log. There seems nothing wrong in the responses, nor are there any errors.
• in C:\Users\\AppData\Local\KNX\ETS5\Log\ETS5.log, check if there is more info about the problem (look for the latest occurence of "Object reference not set to...").
• as temporary workaround, you can try setting the server config to routing = true, and program by selecting the ets network interface. This won't use any connection, only multicast. So this would rule out any connection issues.
• I don't have an exact RF setup at hand right now, but I just tested your server config with another usb stick, which works fine.
• I found this: https://support.knx.org/hc/en-us/community/posts/360009385380/comments/360002168079 . The suggestions was to close/open the ets project. Could that be?

[lukasriegel]

Well - the device info error still persists. But as you said it's not important I stopped investigating this. Could you give me more details regarding the temporary workaround you mentioned? I'm not sure how to perform the steps.

Here are the ETS logs when I start ETS and try to program As I restarted ETS before the export of the log file, I assume that simple restart won't help. Not sure if this is the expected/normal behavior. But I see a Disconnect before the actual error. Maybe "Object reference not set to an instance of an object" means that there is no available connection to perform the programming step on?

[lukasriegel]

Maybe I'm following the wrong approach. My understanding is, that I'll be able to use a KNX RF USB stick to create a KNXnet/IP server without additional hardware. As the server setup seems to be fine - you already said 'There seems nothing wrong in the responses, nor are there any errors.' - I assume, that the next step (and maybe error) is in the ETS setup. Do the screenshots (ETS) above provide enouch information to judge if this minimum setup will work? 1 Line in ETS with my switch/actor, group adresses already assigned.

[calimero-project]

Yes, the usb stick is "hidden" behind the server, so the ets most of the time does not even care about it, it thinks it's talking to a knx ip server. The stick itself is only important for things like apdu length, domain address, etc.

There is a connection established (otherwise ets wouldn't send a disconnect) and the ets does send feature request messages. So that works.

Do you even get to the message on the right-hand side in the pending operations tab, where it asks "please press programming button"? ("Programmierknopf drücken").

Workaround: in the server-config.xml, you have set routing="false". Set this to true, restart server, you should see in the ets a new network interface for IP 224.0.23.12. Select that for programming, it uses multicasts without establishing a connection. That is what i meant to rule out any connection issues with tunneling.

ETS will during configuration usually prevent you from doing invalid line setups etc. and I don't see anything wrong with it. (As said, when I use your project, I get to programming stage without problems).

Maybe send the ets5 log file (there is not really anything confidential in it).

[lukasriegel]

Thanks for your explanation!

Ah sorry - forgot to attach the logs to the previous comment. error.txt The error appears immediately after pressing the 'Programmieren' button.

Ok - I hope I got all required config steps for the workaround. With that in place I get the following when hitting the program button.

Not sure if this is an option for you, but if you like we can schedule a short troubleshooting skype/zoom/whateveryoulike session. Maybe faster and more efficient.

[calimero-project]

Click "Beibehalten". A knxnet/ip server is only specified for tp1 networks, that is what the dialog is trying to tell you.

I will check the error log, if i run out of ideas we can connect otherwise.

[lukasriegel]

So after setting routing="true", removing reuseCtrlEP="true" and adding a additionalAddresses again I can now at lease clicking "Beibehalten" at least I did pass previous error message and come to the programming stage.
But seems like than again sth. is going wrong. I'm stuck in the 'Herunterladen' phase but then nothing is happening (at least in 5 minutes or so).

ETS5.log.zip

[calimero-project]

I could recreate at least a small part of the behavior I read in your logs. Try to change the address ETS assigns itself in the network interface for ip routing (7.1.0) to something unused (e.g., 7.1.4 or 7.1.3). This should prevent some of the weird disconnects I see in your latest ets5.log.

So in calimero server log, a line like server-side KNX IP routing service 224.0.23.12: 7.1.0->7.1.x L_Data.ind ... should become server-side KNX IP routing service 224.0.23.12: 7.1.4->7.1.x L_Data.ind ... (notice the difference in the source addr).

Also in ETS -> Settings -> Troubleshooting, there is a Logging Level box, which can be set to Extended. Maybe it shows a little bit more, what its doing.

[lukasriegel]

Again moving one step further. Changed the address in ETS to (7.1.10) and changed the ets logging level. With that settings I reached now the state 'Bitte Programmierknopf drücken'. Unfortunately, this operation times out.

According to the documentation of my device a simple press of the programming button should trigger the programming mode (At least I can see the red light turning on).

calimero_logs.txt ETS5.log.zip

[calimero-project]

Finally something I can fix on the server side. There was a regression due to filtering secure services on usb (your stuff is not secured, you're just an unlucky bystander). It's on master, you can pull.

Your device flashing red indicates programming mode, that's absolutely fine.

[lukasriegel]

I checked out the recent master branch. Unfortunately, I don't see any difference in the behaviour. Collected ets and calimero logs are here: ETS5.txt logs.txt

[calimero-project]

There is a difference, in that the frame is sucessfully broadcasted, and the usb stick is not reporting any error. However, as you can see in the response from the usb stick, e.g.

EP 1 IN I/O request 01131c00080014010300002e0a020802ffffffffffff05b0d0710000000001

the fff.... indicates the domain address, which is probably not what you want. Decoded this is

7.1.0->0/0/0 L_Data.con (pos), RF DoA ffffffffffff, LFN 1, RSS=void, Battery OK, system priority hop count 5, tpdu 01 T_Broadcast. Your RF device won't probably answer on that domain.

Also the length is truncated. My guess is the following: RF frames should ignore a specific length field (always set 0), but the .con seems to truncate the frame by interpreting that field. I cannot say what the transmitter is actually sending out.

) For the domain address, you can try setting again the domain address in the server config, and see if that changes something. I am certain reporting fff... back in a response isn't even specified. ) For the length stuff, you can try the following (I won't commit that in the repository, because I think this behavior seems wrong): in this line in calimero-core https://github.com/calimero-project/calimero-core/blob/68cc41a08ee8b95a7f4a59da89d3258f8c11e749/src/tuwien/auto/calimero/cemi/CEMILDataEx.java#L550 always assume rf to be false, i.e.: os.write(data.length - 1); This will specifically avoid the check for RF frames in the length field.

(As said, I don't have a usb rf stick at hand right now, so i cannot even try it).

[lukasriegel]

I changed the config to <knxSubnet type="usb" medium="rf" domainAddress="000000004b01"/> and performed the change in CEMILDataEx.java as you suggested: Result are the following logs: logs.txt ETS still reporting that there are no devices in programming mode after 5 minutes

[calimero-project]

(You don't need to let the ets run for 5 minutes, you should see a progress change after a few seconds.)

The confirmation (.con) is now (2e0a020802000000004b0104b0d0710000000601c8000000b001), meaning 7.1.0->0/0/0 L_Data.con (pos), RF DoA 000000004b01, LFN 4, RSS=void, Battery OK, system priority hop count 5, tpdu 01 c8 00 00 00 b0 01 T_Broadcast, A_SystemNetworkParameter.read

The .con now looks fine (also LFN is correctly replaced), which is in both accounts an improvement:

1. setting the domain address is important, otherwise your stick will send a bogus one (maybe it's DoA is not configured).
2. length field is interpreted, but with your change the whole frame is confirmed.

But there is no response from the device in programming mode (7.1.50 i guess). Your device you want to program is in this RF domain?

[lukasriegel]

Yes 7.1.50 is the device I'm trying to programm. It's a MDT RF-TA55A2.01 - so you are right with RF domain.

[calimero-project]

What I meant specifically with DoA, and what I found skimming the page you linked is (Technische Information MDT KNX RF+, Stand 11/2019: 4.4.2 / Liste Pkt 2.):

Des Weiteren wird durch den Programmiervorgang der KNX RF+ Geräte die Domain-Adresse in das Gerät geschrieben.

So I think searching for a device that needs to be programmed with a domain address which is yet to be programmed is futile. I don't remember enough about RF to know where such address is documented initially (on the product packaging?).

[lukasriegel]

As per my (very basic) understanding the domain address would be set in the RF/TP Coupler. Which in my case of the setup is not in place. Should we come to the conclusion, that the chosen hardware setup simply did not work?

[calimero-project]

Yes, let's conclude on that. It did not work as expected, and I completely understand you basically just wanted your devices programmed without a hassle. I know that feeling :)

[lukasriegel]

Ok - nevertheless, many thanks for your intensive support! Let's conclude, that USB RF with MDT KNX RF+ will not work. Assuming, that one could get a working setup with a regular USB TP stick and the MDT line coupler (RF-LK001.02)

[calimero-project]

I did look at a wireshark trace of trying to program RF devices with your ETS project, and noticed that certain system broadcast messages were not being sent as system broadcast. Long story short, I added a "manual" adjustment in the server before forwarding them to the usb stick, and after some hiccups were able to program them over KNX IP. Maybe you can give it a try.

[bmalinowsky]

Closing due to inactivity.