Hi,
I want to unify the Network-Code of Windows Phone and the default .NET-Code. While reviewing the currrent differences I noticed, that the callbackQueue is only dequeued in the CallbackLoop, however the CallbackLoop is not executed on Windows Phone, so I fear, that callbacks are broken there.

Could you verify my observation?

However, in this moment I am installing the WP7-SDK and if everything goes well, I would fix this bug as a side-effect.

Again something for discussion as it would need API-changes:

The Callback-API could be implemented using events (http://msdn.microsoft.com/en-us/library/awbftdfh.aspx).

Benefits

• type-checks are done at compile-time (currently you accept any Delegate for RegisterCallback and check the type during runtime)
• more than one consumer can receive the same callback (however all consumers would share the same settings)
• The conventions for Events specify a sender, so problems like this (http://www.tinkerunity.org/forum/index.php/topic,262.0.html) would be solved for C#
• Ability to remove Callback-Handlers (http://www.tinkerunity.org/forum/index.php/topic,330.0.html)

Costs

API-change

Topic opened for discussion :D

P.S.: I would do the coding/documentation-part if you'd like ^^

From what I see in source code it is important for Tinkerforge language binding in C# to be usable from .NET 2.0. Why is that?

Later versions of .NET provide many new feature (like TPL and async/await), which could improve (especially simplify) the language binding API. So it could be easier to use. At least to the extend I understand it.

As long as you could consider using a newer version of .NET I would be happy to provide some ideas / proposals how to improve the API.

Thanks for this awesome tools anyway.

Small heads-up, I am currently unable to generate the code, first error I found was a call of print like this:

print "this is wrong"
print("this would be better")

But after resolving this there are more errors left, that I will investigate later.

If you are not faster, I will probably try to turn this into a Pull Request.

It would be good to add an automatic module name attribute to the Java binding in order to allow it to be used with Java Platform Module System (eg. as mentioned here - https://dzone.com/articles/explicitly-naming-automatic-java-modules )

I think that this might be possible to add via an extra line under https://github.com/Tinkerforge/generators/blob/master/java/pom.xml.template#L61

<Automatic-Module-Name>com.tinkerforge</Automatic-Module-Name>

Performing this Example results in a Memory Leak.

"use strict";
let Tinkerforge = require('tinkerforge');
let HOST = 'localhost';
let PORT = 4223;
let UID = 'v7e'; // Change XYZ to the UID of your Accelerometer Bricklet
let ipcon = new Tinkerforge.IPConnection(); // Create IP connection
let a = new Tinkerforge.BrickletAccelerometer(UID, ipcon); // Create device object
ipcon.connect(HOST, PORT, function (error) {
    console.log('Error: ' + error);
}); // Connect to brickd
// Don't use device before ipcon is connected
ipcon.on(Tinkerforge.IPConnection.CALLBACK_CONNECTED, function (connectReason) {
    // Set period for acceleration callback to 1s (1000ms)
    // Note: The acceleration callback is only called every second
    //       if the acceleration has changed since the last call!
    a.setAccelerationCallbackPeriod(1);
});
// Register acceleration callback
a.on(Tinkerforge.BrickletAccelerometer.CALLBACK_ACCELERATION, 
// Callback function for acceleration callback
function (x, y, z) {
    // const _test = {
    //     x: x / 1000.0,
    //     y: y / 1000.0,
    //     z: z / 1000.0
    // };
});
console.log('Press key to exit');
process.stdin.on('data', function (data) {
    ipcon.disconnect();
    process.exit(0);
});

Memory Usage is growing.

Node Version 9.5

OS Windows 7 64 Bit

Thanks for the vast range of bindings for Tinkerforge bricks. Is it planned to also port the bindings to Julia (https://julialang.org/)? I would be interested in using such bindings in various projects but I have to admit that I am a bit overwhelmed by implementing my own version of the IP connection. Is there any documentation about the interface to Brickv that I am missing?

Is there any reason not to switch at least to JDK7? JDK6 is EOL and with JDK7 IPConnectionBase could be extended to

public abstract class IPConnectionBase implements Closable { @Override public void close() { disconnect(); } }

That way i can use the IPConnection as follows

try(IPConnection ipconntion = new IPConnection()){ //snip }

I use a .NET 8.0 ASP Net Core application on a Raspberry PI 3 (Raspbian bullseye, 32 bit).

After upgrading the Tinkerforge API from 2.1.31 to 2.1.32 I get permanently disconnects (several times per second).

The problem does not occur when running on Windows.

In brickd.log I find quite often (for every disconnect) :

2024-03-28 17:25:12.814733 <I> <client.c:263> Client (N: 192.168.1.205:45274, T: plain-socket, H: 23/23, B: 0, P: 0, A: disabled) disconnected by peer

I guess the problem is related with the latest fix "Fix System.AppDomain.Unload timeout".

I am not entirely sure, if this is the correct repo for this report. I do have a problem with some of the bricks in a noisy environment. Noisy in this context means, that every once in a while the MCU on the Master Brick seems to send garbarge and if the ip connection receives this garbarge, its thread crashes.

I am using the Python implementation and I have the following taceback:

Exception in thread Brickd-Receiver:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/sensorDaemon/sensors/tinkerforge/ip_connection.py", line 1052, in receive_loop
    self.handle_response(packet)
  File "/sensorDaemon/sensors/tinkerforge/ip_connection.py", line 1355, in handle_response
    function_id = get_function_id_from_data(packet)
  File "/sensorDaemon/sensors/tinkerforge/ip_connection.py", line 41, in get_function_id_from_data
    return struct.unpack('<B', data[5:6])[0]
struct.error: unpack requires a buffer of 1 bytes 

It would be nice to see some kind of exception handling, when unpacking structs coming from untrustworthy sources.

I'm using the C# Bindings, and it would help, if you remove the trailing 0's or stop copying on a zero char.

When calling functions with the optional callbacks, the callback never gets called even though the desired function is executed.

Example:

const tf = require('tinkerforge');
const ip = new tf.IPConnection();

ip.on(tf.IPConnection.CALLBACK_CONNECTED, () => {
  const lcd = new tf.BrickletLCD20x4('qHW', ip);
  lcd.backlightOn(() => {
    // This never gets called
    console.log('Callback called');
  });
});

ip.connect('localhost', 4223);

This should be fixed. Some implementations might not work because they're always waiting for a callback that will never be executed.

Subj is broken due to commit cf5fce5 changing registration routine (filtering out callbacks with ID == 0).
Not sure whatever was an intention - to change IPCON_CONNECTED_CALLBACK id to something other than 0 (not done), or the filtering by callback id during registration is buggy.

Hi,

I thought I found some bad behavior in your reconnect-logic, however this seems to work ^^

But nevertheless I found three other threading-issues that are much older (the second and third issue were found during the writing of this).

According to the MSDN, the NetworkStream is not thread-safe. However it is accessed in IPConnection.Write() and in the receive-loop without proper locking. This can cause errors.

Another problem can be found in Device.SendRequestExpectResponse()
After aquiring the write-lock, you first send the message to the device and after that set the expectedResponseFunctionID. Assuming the answer comes in before the next line of code is reached (which is at least possible) the answer will be discarded, because it does not match the expected (because unset) function-id. Switching assignment of the function-id and write will help here.

Now lets assume the answer takes much too long, longer than the timeout, then the following can happen:

1. timeout exceeded -> exception
2. answer arrives -> compare to expectedResponseFunctionID -> match -> enqueue
3. call another function with expected response
4. dequeue wrong answer
5. return wrong result

Steps 3-5 will repeat from now on (at least until the dequeued answer is too short, then the program will blow up).

The last scenario seems quite unlikely, as a message would have to arrive after more than 2 seconds, but is it impossible?

At least you should reset the expected function to something invalid before throwing the TimeoutException. This is however not perfect, as the response could come in right between the timeout and the reset of the expectedResponseFunctionID. But I don't know how to fix this elegantly.

As a last comment on API-breaking changes:

I was just flying over the new IPConnection.cs and noticed many occurences of ints and shorts that should be enums. I will need to review the new IPConnection later and in more detail to fully understand it, so there might be occurences that can't be expressed as enums.

However at least the enumeration_type should be an enum, because it is public and changing it later would be API-breaking.

public enum EnumerationType : byte
{
    Available,
    Connected,
    Disconnected
}

To my mind this enum should be defined outside the IPConnection class.

Other occurences (connect_reason, connection_state) might or might not be suitable as enums, but at least a change is not immediately neccessary, as they are not publicly visible.

edit: I think the response-expected-thing is also affected here, but I don't understand how this is supposed to be used, so I might be wrong.

Probably it is just my missing knowledge about Python, but when I execute python generate_csharp_bindings.py I get the following error:

Traceback (most recent call last):
  File "generate_csharp_bindings.py", line 33, in <module>
    import common
ImportError: No module named common

I'm using Python 2.7.10 as provided by official docker image (i.e. with buildpack-deps). I do understand that the script cannot find common.py in the base folder. I did git clone [email protected]:Tinkerforge/generators.git generators and do have the common.py file. Do I need to set any path?

Just to split the discussion another issue for that one:

How is ResponseExpected supposed to be used?

In the description of protocol 2.0 I saw the use-case of "blocking" setters. It makes sense to me that this should be possible.

But looking at the current version of the C#-Bindings there are many things confusing me:

• Who is supposed to call setResponseExpected/getResponseExpected?
• Why do the subclasses of Device not fill responseExpected[] with their own function-ids and default values?
• why is it possible that a getter does not expect a response (no resp-flag), but still in every case calls SendRequestExpectResponse?

Maybe I don't fully understand the final use cases, but I'd rather not provide the setExpect/getExpect-methods and instead provide two different setter-methods:

• setFoo(bar)
• setFooAsync(bar)

The Async-suffix is close to naming conventions used in the .NET-System-Library (close, not equivalent)

Hi,

while reviewing the C#-Code I stumbled upon the sequence-numbers and depending on how they are intended this is an issue or not:

Creation of sequence numbers is done outside any locking environment, this means the PC (= the Bindings) could send sequence numbers to the stack, that are neither in sequence nor continuous.
worst case example:

1, 2, 2, 4, 6, 5

The "2, 2, 4" can occur as GetNextSequenceNumber is neither locked itself nor by its callers. So a Thread might suspend after getting a sequence number, the next thread gets the same sequence number (because Thread 1 did not increase it until now) and afterwards both threads increase the sequenceNumber by one each.

The "6, 5" can occur as a Thread might get a number, but before sending the request it gets suspended and another thread gets and sends the following number. Afterwards the first thread sends his number.

Question left: Is this a problem or not? If you only need sequence numbers to have some kind of a checksum in your replies this will not be a poblem at all. But if you in any way want to rely on the sequence there will be changes neccessary.

When tinkerforge = "=2.0.18" is imported, cargo failes to pull the crate and build due to a yanked dependency.

tinkerforge 2.0.18 depends on --> https://crates.io/crates/tinkerforge/2.0.18/dependencies
hmac ^0.7 which is part of that tree, is specified as ^0.7 resolved by cargo to: ^0.7 := >=0.7.0, <0.8.0
hmac 0.7.0 or 0.7.1 (which both fall withing above definition) depend on crypto-mac ^0.7 visible here --> https://crates.io/crates/hmac/0.7.1/dependencies
crypto-mac 0.7 is meanwhile yanked as visible here --> https://crates.io/crates/crypto-mac/versions

This breaks the dependency chain, so I think an update nessecary.
Note that specifiing ^0.7 via cargo might result in a different behavior compared to other languages and package managers.
The speccification is visible here: https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements

Hello,
I can connect to and get various sensor data from my IMU v2 (with realistic values), but I run into trouble when I try to query the configuration. Specifically, calling imu_v2_get_sensor_configuration sets all the output values to 204 (which is invalid for all of them and suspiciously looks like uninitialized memory), then indicates success by returning 0.
I had a quick glance at the code, but cannot quite tell where these values are supposed to be copied: The single memcpy in ip_connection::device_send_request appears to only deal with the header (copies a chuck of size response_packet.header.length, which is always 8 bytes for me).

It would be great if there was a function built into the Java bindings that maps device ID to the Device sub-class that supports it. I would imagine this could also be useful in other languages.

Something like -

public Class<? extends Device> getDeviceClass(int deviceID)

At the moment I need to keep a manually built list up-to-date to auto-create devices on enumeration, as in this code -

https://github.com/praxis-live/praxis/blob/master/praxis.tinkerforge/src/net/neilcsmith/praxis/tinkerforge/TFDeviceFactory.java

After several timeouts the wrapper disposes the socket and starts throwing ObjectDisposedException for Sockets.NetworkStream type. Shouldn't it kick in auto-reconnect if set and during this time shouldn't it set the IPConnection state to CONNECTION_STATE_DISCONNECTED or CONNECTION_STATE_PENDING instead?

Is this something that should have been done here?
https://github.com/Tinkerforge/generators/blob/master/csharp/IPConnection.cs#L2345

Hi, its me again...
this time I wanted some discussion before starting to code :)

In the forum I once started a Thread on this (http://www.tinkerunity.org/forum/index.php/topic,274.0.html).

I have to admit that I find it quite annoying to have to use out-parameters on all single-return Functions as it breaks common patterns.
Example, the code could look like this:

if(display.IsBacklightOn())
{
  Console.WriteLine("The room has a temperature of {0} °C", temperature.GetTemperature() / 100.0);
}

but out makes me write this:

bool isBacklightOn;
display.IsBacklightOn(out isBacklightOn);
if(isBacklightOn)
{
  short currentTemperature;
  temperature.getTemperature(out currentTemperature);
  Console.WriteLine("The room has a temperature of {0} °C", currentTemperature / 100.0);
}

This is the maximum possible amount of clutter for only some cases, where it is neccessary.

If you agree with me, I would make the following changes to the binding-generator:

• all methods with a single out value will return their value via "return" instead of "out"
• all methods with multiple out values will return all values via out (like it is currently done)
• for compatibility there will be also be the "old" single-out-param methods marked with an ObsoleteAttribute

Ipconnection.class is missing in the latest precompiled jar ( Source is available throug git)