Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Running SIMPL debugger continuously
|
I'm?not a full-time Crestron programmer; more of sysadmin, trying to build more robust observability into all of our room designs.? The signals in SIMPL debugger are quite valuable information, and I'd like to log certain signals continuously at all times, ideally sending to an external syslog server.? Is that possible?? The debugger seems to disconnect after a few minutes of inactivity.? I do have syslog enabled, but it doesn't seem to include this debug information. |
|
Hello Elliot,
You can try using C5 Debugger () to continuously log events, but its not really the recommended way to do it. The best way would be to create a custom library that can log specific events to a syslog/serilog type server. This would require writing custom code for each thing you want monitored and logged. |
|
I wrote 3 SIMPL+ modules that will let you pipe an unlimited number of signals out to a single TCP port, and then I wrote a Python script for an external computer (RPi, PC, etc.) that will consume that TCP port and stream everything to an MQTT server.? (MQTT server can be thought of as a lightweight database server that doesn't save anything -- it's just a networked bag of variables in a tree hierarchy).? You can effectively watch with a tool like MQTT Explorer (for Mac) to see realtime values change, look at history, trends, of specific variables etc.
3 SIMPL+ modules because one's for Digital signals, one's for Analog signals, and one's for Strings.? You can expand the block to export up to 100 signals, and just use multiple blocks if you need more than 100 signals.? There's no limit to the number of blocks and they can all push to the same TCP server port. I'd like to think it's pretty lightweight?? It does the bare minimum to get the data out, and doesn't overwhelm my own processor at all.? I'm watching several hundred signals 24/7 and using the MQTT to drive other scripts and automation outside of the Crestron processor environment. I'm willing to share these modules |
|
Also don't forget Cresteon Fusion which will pump whatever data you pick into a SQL table and the you can construct your data into PowerBi, works great for generating bigger pictures about system use, Errors, help requests, mic battery levels (anything). Then you can make in formed descisioms about correct system development or push training and information to change how users interact with the system and prove your results as time goes on
|
|
Thanks everyone, for the ideas. Michael, that MQTT module is very cool!? I tested it and it works as advertised.? Great for temporary debugging with MQTT Explorer.? Have you thought about building the MQTT client into the module, to remove the need for that separate python app? It might also be cool to run a little HTTP server on the processor that serves metrics in Prometheus format.? That's what I do on my Qsys Cores using this plugin: . On Thu, May 30, 2024 at 10:56?PM RK-X via <rkx1984=[email protected]> wrote: Also don't forget Cresteon Fusion which will pump whatever data you pick into a SQL table and the you can construct your data into PowerBi, works great for generating bigger pictures about system use, Errors, help requests, mic battery levels (anything). Then you can make in formed descisioms about correct system development or push training and information to change how users interact with the system and prove your results as time goes on |
|
Awesome, thank you for trying it and sharing your experience with the group ¡ª I really like Python. I also really like Crestron gear.? Both do something specific really well and I¡¯ve gotten lots of value using both together.? Python isn¡¯t my first or ¡°native¡± programming language but it is noteworthy for how massively productive you can be with it, for so little effort learning it.? Its community prioritizes simplicity and they¡¯ve excelled at delivering it.? Paid ChatGPT can crank out quality Python examples that can be pasted from, speeding development.? Crestron¡¯s hardware and their paradigm with reducing high quality hardware to SIMPL integration has advantages that shine the most when you stick to its simplicity that I feel is chipped away from, when we seek to have a Crestron processor do everything including the kitchen sink.? If you flew on an airplane and found out that the same CPU runs your seat back gaming experience as well as the cockpit instruments, you¡¯d be appalled for the lack of separation.? I feel the same way about anything that adds to the latency of a home¡¯s responsiveness (as well as a bootup time I already think is too much) for critical functionality like lighting.? If you¡¯ve driven a Tesla you might feel their infotainment system has timing glitches¡ it¡¯s for being a single computer that does too much.? Since a single industrial-mount Raspberry Pi can be the on-premise MQTT server, and since it¡¯s not too hard set to run full-time Python scripts on boot (either on the same pi or another), I view it as a sweet spot.? Raspberries are up in under 30 seconds.? But more power to anyone who sees the value in having it all in a single appliance and wants to take a moment to whip out S# and implement this there.? Mike On Wed, Jun 5, 2024 at 7:18?PM Elliott Balsley via <ebalsley=[email protected]> wrote:
|
|
Fair point, MQTT is fairly complex and it would be hard to write by hand without a library. The more I think about operationalizing this at scale, I'm not sure if MQTT is a good fit for my situation.? What do you think about sending syslog (RFC 5424) directly from the processor?? It's a very simple protocol running on UDP.? If packets occasionally get lost, no big deal.? I wrote something similar for Qsys:? I have around 100 Crestron processors around the world, so adding a Pi on each one adds some operational challenges.? For me, RPi is a great tool for experiments, but not robust enough for production. On Wed, Jun 5, 2024 at 9:36?PM Michael Caldwell-Waller via <bowser77=[email protected]> wrote:
|
|
You totally could do it exactly as you propose for debug purposes, especially if it's just for inspecting variables in real time and you don't care about packet loss.
For me, I'm actually driving other good automation from my MQTT that don't make sense to implement on Crestron processor, so I'd have unacceptable malfunctions if I had packet loss, and had to choose TCP.? That said, the TCP Server symbol isn't part of my code -- it's one you'd have added yourself following my Readme, and you could substitute TCP Client, UDP, RS232, or any other symbol in its place.? (e.g. TCP Client to make your processors push messages through the internet connection to your other infrastructure)? If you're familiar with the Syslog packet format, you could probably tweak the packet format in the S+ scripts I wrote, to output Syslog UDP instead of the plaintext I'm doing. An example of "other automation" I'm doing with MQTT is that pesky Pac2 scheduler issue I keep reading about on this forum.? Yeah, it bit me too, but I handled it by deleting all my affected scheduling entries from D3, and then just writing a Python script to "be" the scheduler and trigger events on Pac2 externally, either based on time or MQTT data.? Chatgpt helped me come up with short code snippets to calculate sunrise and sunset using a 3rd party library.? Other python-based automation I do is SMS-based two-way text bots to send commands to the "house" and receive notifications back over text.? All on RPi, using Twilio for the SMS. Agree, RPi sold as the bare board or in plastic hobby packages isn't robust for production -- on the other hand, some companies have made industrial versions that are (especially using the "compute module" daughterboard version of RPi) meant for pro applications.? Higher end metal / dinrail enclosure pi's provide proper cooling and avoid using SD cards as primary storage (weak spot).? Robustness is also in the eye of the beholder.? I think a lighting system whose manufacturer repeatedly breaks basic functionality like scheduler -- or a dev environment whose performance grinds to a complete halt when you click "debug" on multi-core multi-GHz processors -- could be questioned for robustness :) (the whole reason we're chatting about this topic, the Crestron debugger is unacceptably slow and the silly Python thing I wrote -- or Syslog and other ideas we're discussing here -- outperform it in spades and give us back the basic functionality we're nearly deprived of by not wanting to wait on the "robust" product) -- but Crestron does so many things right and my continued business and support reflects that.? That said, my lighting hasn't missed a single event since I switched to a Python scheduler running on a Pi, others mileage seems to continue to vary :) Mike |
to navigate to use esc to dismiss