--- On Thursday, January 9, 2025 2:19 PM, Michael Caldwell-Waller wrote:

Well yes I'm going to agree with you, the protocols are different (I'm assuming
they are both RS232 though). And the NX-8E fix (it's on GitHub
) is only going to directly help
your home installation at best. The underlying principle of what's wrong,
could be exactly the same. I'll share what the problem was in terms of NX-8E,
and how that might apply to the Vista, assuming it's the same conceptual
problem.

On the NX-8E, if the host and the NX-8E both send something at the same time
(within hundreds of milliseconds), the NX-8E can't tolerate it, and
malfunctions. Any time NX-8E begins transmitting a notification (about a door
open/close etc.), it wants the event notification acknowledged before it will
accept any commands. If a command (like disarm) was already inflight, and
finishes arriving when the NX-8E suddenly wants an acknowledgment, it gets
ignored and the NX-8E's serial processing freezes for about a second, and
afterward, it still wants an acknowledgment before it will accept
commands. Crestron is left to guess whether the command worked. NX-8E is a
difficult negotiator.

How this might apply to the Vista,

Conceptually, the Vista may have the same design flaw -- requiring
notifications acknowledged, and burping if a command is received when an
acknowledgement was expected.

The way I discovered this, is with the Saleae Logic Analyzer, the smallest Pro
model (which can analyze RS232 level voltages), connected to my MacBook. It's
really easy to see when the two sides are stepping on one another. Even
without looking at the messages, you can start to deduce who is "requesting"
and who's "responding" just by looking at the timing of who is
transmitting. You can also pick up when both sides start transmitting at the
same time, and whether that results in a chaotic interruption to the normal
flow.

If you see the problem, then it's within reach of solving with an Arduino.

All the Arduino is doing, is looking for occurrences of both sides transmitting
at the same time. If that is detected, it memorizes (into RAM) the packet that
the host was sending, and then intentionally corrupts the packet in transit to
the alarm (so the alarm system receives "nothing valid" -- which it will
ignore, and this prevents its malfunction). We let the alarm system talk
first. Afterward, Arduino sends the acknowledgment the alarm system desires,
followed by the original memorized message from RAM. Crestron is none the
wiser about what happened.

Same principle, could work the same. The only thing Arduino code cares about
is the format of a valid packet (including checksum etc.) and how to prevent a
partially transmitted packet from completing successfully -- it doesn't need to
know any details about the alarm system protocol beyond that.

Mike


On Thu, Jan 9, 2025 at 10:50?AM Tony Golden wrote:

I'm pretty sure the GE protocol is completely different than the Vista-BPT, but
thanks for the ideas.

I'm scheduled to go back to the site next week, and will hopefully be able to
duplicate the problem while watching Debugger. At the very least I'd like to
determine which conditions cause it to happen, but finding a solution or work-
around is the ultimate goal.

I'll update this thread with my findings, but in the meantime any other ideas
are also welcome.

--- On Thursday, January 9, 2025 at 11:41 AM, Michael Caldwell-Waller wrote:

NX-8E!!

Within this last year, I did a deep dive on the serial protocol interaction
between the NX-8E and the host, and am 100% sure I discovered the causation

and

the fix for the intermittent disarm issue (or more broadly, the sending of

any

command to the NX-8E whenever notifications of any kind are enabled on the

NX-

8E). It's a timing race condition between the Crestron processor and the NX-

8E

that I solved by inserting an 8-bit Arduino board between the two, that

detects

and recovers from the condition seamlessly. I am very happy with the
outcome. It's impossible to program this fix on the Crestron processor

because

the multitasking nature introduces some unpredictability in the timing of the
serial response that aggravates the race condition. The Arduino solution has
no such constraints and completely mitigates the issue because it can be
precise on the timing. Let me know if you want more info on this.

Mike

On Thu, Jan 9, 2025 at 9:36?AM Randy S wrote:

I've been using a similar but older NX-8e panel in my house for years with

the

same intermittent disarm issue. I did a bunch of digging and testing but

never

found a cause or solution but plenty of folks had the same problem. My

hacked

solution is to use an input on the alarm panel programmed as a dry contact
controlled arm /disarm toggle to disarm it with a relay on the processor,

using

a passcode programmed into the Crestron system that matches the one in the
alarm panel. The buttons on the touch panels still arm it normally via

serial

for home /away but the disarm is controlled by the relay with FB from the

alarm

panel so it can only trip the disarm input when it's already armed. It's

not

perfect since you have to hard code the disarm passcode in the processor so

you

need to know the client's passcodes(s), and if they use more than one you

would

need to add a password module for each different passcode. And if they

change a

code you need to change it in the SIMPL programming to match. Also the arm
buttons need to use the Instant Arming with no passcode needed, though I
suppose you could buffer the touch panel keys from the alarm module to the
password module depending on the alarm's state.

But it does work100% of the time. In some ways it's sort of handy since I

can

disarm the alarm directly from the processor without having to punch in a

code

with a stepper so it's easy to use as part of an automated sequence.

So would I recommend it as a solution in a client's home? Eh, maybe, but

only

if the only other solution is to replace the existing alarm system.

--- On Thursday, January 9, 2025 at 11:41 AM, Michael Caldwell-Waller wrote:

NX-8E!!

Within this last year, I did a deep dive on the serial protocol interaction
between the NX-8E and the host, and am 100% sure I discovered the causation and
the fix for the intermittent disarm issue (or more broadly, the sending of any
command to the NX-8E whenever notifications of any kind are enabled on the NX-
8E). It's a timing race condition between the Crestron processor and the NX-8E
that I solved by inserting an 8-bit Arduino board between the two, that detects
and recovers from the condition seamlessly. I am very happy with the
outcome. It's impossible to program this fix on the Crestron processor because
the multitasking nature introduces some unpredictability in the timing of the
serial response that aggravates the race condition. The Arduino solution has
no such constraints and completely mitigates the issue because it can be
precise on the timing. Let me know if you want more info on this.

Mike

On Thu, Jan 9, 2025 at 9:36?AM Randy S wrote:

I've been using a similar but older NX-8e panel in my house for years with the
same intermittent disarm issue. I did a bunch of digging and testing but never
found a cause or solution but plenty of folks had the same problem. My hacked
solution is to use an input on the alarm panel programmed as a dry contact
controlled arm /disarm toggle to disarm it with a relay on the processor, using
a passcode programmed into the Crestron system that matches the one in the
alarm panel. The buttons on the touch panels still arm it normally via serial
for home /away but the disarm is controlled by the relay with FB from the alarm
panel so it can only trip the disarm input when it's already armed. It's not
perfect since you have to hard code the disarm passcode in the processor so you
need to know the client's passcodes(s), and if they use more than one you would
need to add a password module for each different passcode. And if they change a
code you need to change it in the SIMPL programming to match. Also the arm
buttons need to use the Instant Arming with no passcode needed, though I
suppose you could buffer the touch panel keys from the alarm module to the
password module depending on the alarm's state.

But it does work100% of the time. In some ways it's sort of handy since I can
disarm the alarm directly from the processor without having to punch in a code
with a stepper so it's easy to use as part of an automated sequence.

So would I recommend it as a solution in a client's home? Eh, maybe, but only
if the only other solution is to replace the existing alarm system.

That?s how I?ve implemented it now.

Instead of having multiple module parsing the input stream for relevant data, the whole stream now only gets parsed once in a “dispatcher”-module. Then the device-specific modules only parse the small piece that is relevant to them.

Thanks for that suggestion! I think that reduces the parsing-workload significantly.

?

The Dispatcher-module now has 100+ serial output signals that are connected to the corresponding device-module. Any idea how to make that a bit more elegant?

?

Also thanks to Matt and Jay for your thoughts!

?

Cheers,
Thorsten

?

Von: [email protected] <[email protected]> Im Auftrag von BruteForceIsUnderRated via
Gesendet: Dienstag, 7. Januar 2025 23:58
An: [email protected]
Betreff: Re: [crestron] Programming avice needed: parsing bus system

?

I might go with an option C, which is a bit of the two combined.

?

You have a parsing/sorting module (call it the sorting hat) that looks at incoming data and then sorts it based on subsystems, with each subsystem getting a serial output that feeds your B option modules. Instead of parsing all of your devices in one big module you sort it out so that your specific modules are only ever looking at data that is relevant.

?

As presented, your Option B requires every module to startup and evaluate if the data is for them... easy to implement?in SIMPL but a large overhead in SIMPL+ thread creation that?isn't necessary.

?

When data comes in, your sorting hat main module (ideally it can be GATHERed and only use a single thread) handles it and passes it onto a much smaller amount of modules to deal with it.? My $0.02

?

On Tue, Jan 7, 2025 at 1:10?PM jbasen via <jay.m.basen=[email protected]> wrote:

Hi Thorsten,

In my drivers I do the parsing in S#.? Then I have individual S+ modules for each device type that is supported by the driver.? So, there might be a thermostat S+ module, a switch S+ module, etc.? An S#? HTTPRequestEventHandler receives messages from devices, parses the messages, and then uses the SignalChangeEvents mechanism in S# to pass the parsed data along to the S+ modules.??

S+ modules will look at the data sent from S# and decide if the event is meant for them.? The decision process is dependent on the driver.? For example, with my Shelly driver each Shelly device has an individual IP address.? The S# parsing code passes along the IP address of the device that sent the message.? Then, for example, a Shelly S+ relay module has the devices IP address as a parameter and can decide if the message originated from a Shelly device matches the IP address parameter on the module.? If there is a match it will act upon the data received.? If there isn't a match it ignores the data.

I have used this mechanism over and over with different drivers and it has proved very reliable.? You can look at the Shelly code on my GitHub for an example.

The mechanism is especially good for devices that send JSON because you can use Newtonsoft for parsing.

Hope this helps

Jay

On 1/7/2025 7:07 AM, Thorsten K?hler via wrote:

Hi,

?

I?ve got a bus system called “LCN” installed in my house. It?s similar to KNX, but different. ?

The bus is connected to the LAN via gateway and I?m able to send and receive commands to the bus to control lighting, relay, etc. and receive status feedback, sensor readings, etc.

Communication is via TCP and ASCII.

I?ve programmed a parser that receives and parses the bus messages.

I?ve done that for a few LCN modules for testing and would like to extend that to all modules and sensors in my house (100+).

?

My question is how would I approach this best:

1. Write a central parsing module (all SIMPL+) that receives all bus messages, parses and separates the messages to all the different modules.
2. Write smaller modules based on the specifics of the hardware modules/sensors that only parse the messages dedicated to each module.

?

?

“A” would lead to one huge module with long and huge parsing flow, but it would be just one module parsing the whole input stream.

“B” would lead to 100+ modules just waiting for messages addressed to the specific module/sensor and then just parse these.

?

I tend to option “B” combined with a central module that opens up and handles the TCP connection and receiving and sending the bus communication.

?

Any thoughts?

?

Thanks,

Thorsten

Hi Thorsten,

In my drivers I do the parsing in S#.? Then I have individual S+ modules for each device type that is supported by the driver.? So, there might be a thermostat S+ module, a switch S+ module, etc.? An S#? HTTPRequestEventHandler receives messages from devices, parses the messages, and then uses the SignalChangeEvents mechanism in S# to pass the parsed data along to the S+ modules.??

S+ modules will look at the data sent from S# and decide if the event is meant for them.? The decision process is dependent on the driver.? For example, with my Shelly driver each Shelly device has an individual IP address.? The S# parsing code passes along the IP address of the device that sent the message.? Then, for example, a Shelly S+ relay module has the devices IP address as a parameter and can decide if the message originated from a Shelly device matches the IP address parameter on the module.? If there is a match it will act upon the data received.? If there isn't a match it ignores the data.

I have used this mechanism over and over with different drivers and it has proved very reliable.? You can look at the Shelly code on my GitHub for an example.

The mechanism is especially good for devices that send JSON because you can use Newtonsoft for parsing.

Hope this helps

Jay

On 1/7/2025 7:07 AM, Thorsten K?hler via wrote:

Hi,

?

I?ve got a bus system called “LCN” installed in my house. It?s similar to KNX, but different. ?

The bus is connected to the LAN via gateway and I?m able to send and receive commands to the bus to control lighting, relay, etc. and receive status feedback, sensor readings, etc.

Communication is via TCP and ASCII.

I?ve programmed a parser that receives and parses the bus messages.

I?ve done that for a few LCN modules for testing and would like to extend that to all modules and sensors in my house (100+).

?

My question is how would I approach this best:

1. Write a central parsing module (all SIMPL+) that receives all bus messages, parses and separates the messages to all the different modules.
2. Write smaller modules based on the specifics of the hardware modules/sensors that only parse the messages dedicated to each module.

?

?

“A” would lead to one huge module with long and huge parsing flow, but it would be just one module parsing the whole input stream.

“B” would lead to 100+ modules just waiting for messages addressed to the specific module/sensor and then just parse these.

?

I tend to option “B” combined with a central module that opens up and handles the TCP connection and receiving and sending the bus communication.

?

Any thoughts?

?

Thanks,

Thorsten

Hi all,?

?

I'm would wondering if any could advise how Crestron able to integrate with Schuco door and windows.?

?

I found Schuco system need the automation manager with integrate with KNX but couldn't find any solution for Crestron.?

?

Do we have to integrate over KNX gateway? Would be very appreciated if you could advise the diagram nad sample program.?

?

Thank you,?

?

?