Strange SUBSCRIBE behavior

kirchh

I'm tinkering with controlling a Blu via Ethernet, and I've observed a very odd behavior. When I issue a SUBSCRIBE, I am then sent messages about changes to the subject control -- UNLESS the changes are caused by a command from the same TCP session that is SUBSCRIBEd, in which case the Blu sends no message.

If this is indeed the intended behavior, it makes coding a 3rd-party control system unecessarily complicated, because I can't simply set up a handler that receives change messages regardless of how they were intitiated and adjusts the user interface appearance accordingly.

So, two questions: Am I correct about this behavior? And, if so, what possible reason would there be to have this behavior rather than simply sending a message to the subscribed session regardless of how the change was initiated?

--Daniel

Scott E.

You have described the behavior of subscribing correctly.

The messages are implemented in this way because we have to protect ourselves from careless programmers who inadvertently cause feedback loops which can crash our box. By implementing in this manner it is very difficult for the user to lock up the London. I understand your comment and why you would like it to automatically respond. I hope you understand that if a box locks up then all the fingers get pointed at us even though it was a poor programmer that caused the problem.

But, no worries! There is a simple way to get the best of both worlds. Because the subscribe automatically responds when changes are made from another method, that means that no polling it required by the programmer. This allows great feedback to Touch Panels and no overhead by constantly polling the device.

All it takes is 2 lines of code to have the London respond with a fully formatted message as you are asking. This is how it is done in the AMX/Crestron modules. You are playing around in AMX Netlinx, correct? Download the module and look at the 'SET_VAL' function. You will see the last two lines of code and in the comments it explains how/what it does. I believe this topic may be a bit too deep to post on this forum.

kirchh

I hope you understand when I respectfully disagree with the decision to, in effect, disadvantage the programmer doing the right thing in order to attempt to minimize unustified finger-pointing at BSS. I must say, I also do not understand how implementing this exception to the SUBSCRIBE mechanism would prevent improperly-written code from causing a loop. If the fear is that a message from the Blu to the controller might be improperly echoed back to the Blu (not sure how this would even be possible over Ethernet), woldn't that same improper echo occur on messages from the Blu triggered by another source?

If you would indulge me, could you provide the two lines in the AMX module that work around this issue? I don't have the modules at hand. I have already created my own solution, which I would like to present, but I'm interested to see the approach used in your modules.

Thanks --
--Daniel

Scott E.

I completely understand why you disagree. And thank you for being so respectful. Unfortunately, these kinds of problems do show themselves every now-and-again and we must protect ourselves. We have had many, many 3rd party programmers work with the London and I rarely get any complaints on the subject once they download the AMX/Crestron modules and they understand how simple it is to get around this issue, and the benfits of greatly improved touch panel responses, multiple touch panel support, and the great improvement of their control system over-all by not having to poll their DSP constantly.

I just returned from Infocomm where we had an AMX panel in the booth and we received many praises about the simplicity of the code and performance of the AMX TP from people who had been using our competitors equipment.

Please download the module. BSS has invested many, many hours creating and maintaing that code specifically for programmers like yourself. This will answer many questions that you have in a very practical manner.