Questions about APIs

[rlebrette]

Hi from France,

I own a Tellstick DUO for some months now and I've recently started to play with the APIs.
I've implemented a RESTful server in Java that acts as a passerel between several clients (web and girder) and the Tellstick DUO.
I've been able to manage most of the aspects of the communication but I'm not sure that I've understood how the API is synchronized internally.
The server is both receiving events from callbacks and device commands from REST services. I'm not sure, but it seems that when the stick receives events from devices it's not able to send commands to devices. How do I have to manage the concurrent access to the core? Since multiple callbacks events are generated when an emitter is working (motion detector or remote control) is it safe to send command to another device at the same time? Do callbacks have to be synchronized with other server threads in the main thread? The API documentation is not clear enough on that point.

Thanks for help.
Regis

[Zapper]

As with all radio the general rule is that you can never receive while you are sending on the same frequency. The receiver is simply drowned by the transmitters signals.

And if you are working in Java then take a look at JTelldus, not actively developed atm but it works. And you dont have to wrap the native api:s it connects directly to telldusd:s sockets.

[rlebrette]

Thanks Zapper for your feedback,
I understand how it works at physical level (waves), my question is more about how the software is internally managing it.
The internals can manage this itself by serializing the operations in the core, is it the case?
I already have played with JTelldus, but what I've done is currently going further (based on telldus-core). All the Java wrappers are perfectly working well, I've no problem to use them separatly, I send command to devices and receive events (mainly raw events that are actually not managed by the core).
I only face "problem" when using the wrappers in a multithreaded environment where some events are raised (and managed in a specific thread) while commands are sent to the devices (by another server thread).
When both are working together it seems that I lose some commands / events.
If the internal software is not in charge of the serialization, I've to serialize myself, it's quite easy when sending commands.
But it's more difficult when concurrently receiving events, we know that received signals are usually repeated multiple time, so it's not atomic, there's always a "risk" that a signal is received when emitting.
How is it handled? or how do I have to handle it?

[Zapper]

Well you could probably do some external makeshift synchronization by utilizing a global send queue and perhaps lock if for a short period of time after an incoming event.
Think the next version of telldus-core is supposed to fix the problem with repeating events.

And about how the internal synchronization is done, if you have enough time on your hands you could probably find it in the source code.

[rlebrette]

That's exactly what I was thinking about and what I've implemented, a queue used to send commands and a delay when receiving an event, it solves most of the problems I was facing. Unfortunatelly some received events are really long reapeating events (Chacon motion detectors are sending 25 times the same message for example) and the introduced delay is making the scenario "detection -> switch light" not really responsive.
I already dived in the driver source code but I'm not sure to understand all the low level aspects, actually I think there's no sync at all.
Finally I think that to achieve a perfect behavior the emitter should be separated from the receiver.

[Zapper]

In case of the PIR sensors they are at fault you can't do much in software if they keep sending their status out on the same band.