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
