Multiple Tellstick Duo

Functionality and usage of the OpenNethome Server
Post Reply
PeterS
Posts: 11
Joined: Sun Aug 20, 2017 5:04 am

Multiple Tellstick Duo

Post by PeterS »

Thank you for a great software. I have been using NetHomeServer on a RaspberryPi for more than a year and is really impressed by the functionality and stability of the software. However, my house is large and I have problems to cover the whole building with just one Tellstick Duo. I have seen suggested solutions like multiple special antennas, multiple servers etc. to increase the area controlled by the the NetHomeServer, but no solution seemed to solve the problem in a good way. Recently I found on the forum that the software support more than one Tellstick Duo connected to the same server. I purchased a second Tellstick Duo and connected it without problems to my RaspberryPie.

The second Tellstick Duo seems to receive signals properly, but no commands from the NetHomeServer seems to reach the Nexa dimmers and switches I have. A quick check on the forum explained that interference between the two Duos make the signal unreadable for the Nexa receivers in my home.

Obviously this is not a new problem, but I could not find any solution to the interference problem on the forum. To me there are at least two potential solutions to this problem:

Manual separation
I know where the Nexa receivers are located and could tell the server which Tellstick Duo to use to reach a specific receiver in the best way. However, I cannot find any support for that in the NetHomeServer GUI. I have no detailed knowledge about this specific software, but I guess it would be possible to add information about the preferred Tellstick Duo to use for a command going to each Lamp dimmer or switch.

Time separation
To minimize the risk for interference between two or more Tellstick Duos transmitting the same signal, we could let the second transmitter send its signals with 100-200 ms delay. This would probably work fine for most of the commands except Toggle commands that would toggle on and immediately toggle of the lamp after a few ms :-) .

Have any of these solutions been tested or would it be worthwhile to give them a try?

/PeterS
stefangsbb
Site Admin
Posts: 313
Joined: Sun Nov 30, 2014 2:16 pm

Re: Multiple Tellstick Duo

Post by stefangsbb »

Hi PeterS,

Thanks, I am glad you like the stuff!!
Your problem is not new, this subject has been brought up before. There are currently only two solutions to the problem:
One is to separate the two transmitters so far, so they do not interfere with each other.
The other solution is to use different brands of remote switches in the two "halfs" of the system. In the Tellstick-Item, you can specify explicitly which protocols are transmitted, so it is possible to separate so that remote switches that are in the overlapping area is of a brand (and protocol) that only one of the Tellsticks transmit.

It would of course be possible to implement the manual separation as you suggest, but it is not in there right now and it would involve adding support in a lot of Items to be generic.

The time separation would be easier to implement, but would be kind of ugly - the delay would have to be almost a second, and that is a bit annoying when operating lamps...

Hope this helps!
PeterS
Posts: 11
Joined: Sun Aug 20, 2017 5:04 am

Re: Multiple Tellstick Duo

Post by PeterS »

Would it be easier to do the manual separation by Room? I.e. all item in a specific room are controlled by one Tellstick and another room is controlled by another... In this case you are using an exisisting property for the separation and eliminate the need to add a new property to all items in the system.
stefangsbb
Site Admin
Posts: 313
Joined: Sun Nov 30, 2014 2:16 pm

Re: Multiple Tellstick Duo

Post by stefangsbb »

That would make a lot of sense from the user perspective, since the room indicate physical location. Unfortunately it would be harder to implement.

The way it works right now, the lamp-Item sends an event on the internal event bus to send the ON command. This event can be picked up by any other Item that subscribes for events of that type, in this case any Tellstick-Item. The event does not currently contain any information about which Item sent it or any indication on who should process it. This is actually part of the strength of the system, since it is easy to add new types of transmitters or handlers without having to change any existing Items.

I can think of two ways of implementing the wanted behavior:
1) In the Lamp-Item, you can specify which transmitter should send the signal. This information has to be placed in the event, and the transmitter has to look at that parameter to decide if it should send the message or not. This code would have to be added to all lamp items and all transmitter items.

2) In the Transmitter Item you can specify a list of which lamps are handled by this transmitter. This means that all lamp items must include their identity in the event, and all transmitters must implement and handle this list. A variation of this is that the lamps include the room they are located in , but it is a bit tricky, since the lamp does not know this - it is the room that knows what items it contains.

Both of these options are possible, but would require a bit of effort to implement, since they involve a lot of Items...
PeterS
Posts: 11
Joined: Sun Aug 20, 2017 5:04 am

Re: Multiple Tellstick Duo

Post by PeterS »

If an item cannot check what Room(s) it belongs to, it seems necessary to create a new location aware Tellstick Item with this information as a user defined attribute. I assume an item can ask a Room about the items in that room, so this location aware Item would just forward commands to other items in its Room. This would eliminate the need communicate information regarding the specific sending Item for each event, hence no need to update any lamp items. This information is fairly static anyhow so I see no need to repeat it at each event.

It seems that an item can belong to more than one Room, so the user could actually create a specific Room for all lamps controlled by Tellstick 1 and another room for lamps controlled by Tellstick 2 etc. on top of the regular Room structure
/PeterS
PeterS
Posts: 11
Joined: Sun Aug 20, 2017 5:04 am

Re: Multiple Tellstick Duo

Post by PeterS »

I think I found a way to solve the interference problem without changing any Items. The Tellstick Item does not have any Enable and Disable methods, but it is possible to disable and enable a Tellstick by removing and adding Nexa and NexaL to the list of transmitted protocols.

I could keep the second Tellstick normally disabled and avoid interference in general. By using a Scenario I should be able to switch of the first Tellstick and switch on the second only when I want to control the remote lamps outside the range of Tellstick 1. The switching will take some time, but hopefully it is quicker than the delay needed for the time separation mentioned earlier in this thread. Nevertheless, my remote lamps are controlled by timers, so even a few seconds delay would not be an issue for me.

This is not as general and elegant as putting the lamps in groups served by a specific Tellstick, but it could solve my problem with a few remote lamps reacting only 30-50% of the times I send a command.
/PeterS
stefangsbb
Site Admin
Posts: 313
Joined: Sun Nov 30, 2014 2:16 pm

Re: Multiple Tellstick Duo

Post by stefangsbb »

ah, that was a clever workaround! I agree with your point previously, that it would make sense to configure rooms in the sending device. There are two problems involved: First of all, the events does not currently contain information about the sender. Either I would have to add that code to all lamp Items, or build some generic feature that always adds that automatically. The second option is possible, and I have been considering that earlier for other reasons.
The second problem is that the lookup risk being a bit slow - for each event the TellStick Item would have to open each Room-Item in its list, get all contained Items and then check if the sender was in that list. It would be possible to cache it, but then the question is when to update the cache... I will consider it for future implementation. It is always good to get input with different points of view to get a better understanding about the problem.
Post Reply