I’ve recently purchased two (for proof of concept) and will need another half a dozen of the above devices. I researched and it appeared from what I could find online that it has 8 opto-isolated inputs, 8 relay outputs and supports MQTT.
To simplify the example, I will have 4 sites, I need input 1 at site A to operate relay 1 at site B, input 2 at site A to operate relay 1 at site C and so on.
I cannot find any way to make these devices bind inputs and outputs to discrete MQTT resources.
The matter is further complicated because the network is a private WAN and has no internet access, but running a small MQTT broker on something inside is easy.
At an absolute pinch, I could live with device A mirroring all inputs to device B outputs and vice versa but it’s not ideal.
Latency is an issue, and bandwidth is limited so constantly polling isn’t an option, it needs to be event-triggered. Any hints on how to do this please?
Throwing raspberry pi’s around the network is not a viable option either!
Hey there, @Ross275815, and welcome to the forum. Glad to have you here.
I think what you’re trying to do is possible, but will probably involve a fair bit of customisation and is not going to be an out of the box solution.
If you have a look on the Waveshare wiki page for this product, there is a guide on setting it up an MQTT feed.
From what I’m seeing here, input and output rules for each unit are just controlled by the Hex Codes that is sent through.
I’m not sure you’d be able to get granular control like you’re describing, with each input and output having its own feed, but as long as you’re categorising each Hex Code correctly and establishing side rules you that sent the commands to a separate device:
Thanks, but this option has just toooo many issues for this application. They don’t have and won’t permit this internal network to see external servers, and their IT people will very strongly push back in installing any additional “servers” (VM, container etc) to run mqttx. Looking through the page you linked it’s seems hideously complicated to do such a simple task - or what would be a simple task if the device simply supported conventional mqtt subscriptions.
It’s looking very much like I will have to see if core will take these back and get something that’ll do the job natively like I thought these did (but seems they don’t!)
These are slave devices; you’re going to need a controller of some type for best operation.
Even MQTT needs a broker. If something else exists on-site, perhaps recycle it. Otherwise, and as much as you don’t want to, use an RPi, even if it’s an Ethernet Pico, to TCP-sync the devices. Claude would make light work of this.
Yes, an MQTT broker as a process on an existing box was ok, and I could have got away with that.
But as these devices don’t make “standard” MQTT calls (where each I/O can be its own subscription), it’s no longer a simple broker install. My original intention had been to reflash the devices with ESPhome, but in my haste to get things under way, I mixed part numbers and bought the wrong units. “ESP32-S3” at the start seems to be the critical distinction for my purposes.
Absolutely, and when the docs showed MQTT support I (blindly and incorrectly) assumed it was standard MQTT - but alas this is MQTT - HEX strings, which are a more complex subset of MQTT and doesn’t operate with a “standard” broker.
Hey there, @Ross275815 I get the frustration here, it would be nice if it just worked with your average MQTT Broker.
That said, I do still think these could be made to work with a local MQTT broker plus a small translation/controller layer somewhere on the private WAN. The broker itself should have no issue carrying HEX or binary-style payloads. All you need is the logic that decodes the input-state payload from one unit and publishes the corresponding relay command to another. Even the translation layer really wouldn’t need much in the way of resources.
[This article](How to Process JSON, Hex, and Binary Data in MQTT) gives a pretty good overview of how to handle HEX Strings in MQTT.
I agree with you, and if it was for a personal project I’d go that way.
Unfortunately, it’s a quoted job for a non-profit organization. I can’t afford to spend the extra time, or the extra hardware over and above the devices, in a quoted job where I was already donating my time to do the setup of what seemed a simple task. Standard MQTT would have ticked those boxes.
The NPO can’t find extra hardware, even a RPI, and the person in charge of their network won’t allow any extra devices to get connected. It was a big enough struggle to get these boards “permitted” and only with a lot of effort from one of the senior people stating they were absolutely required for this project.
So the answer is yes, I’m sure it CAN be done, if time and money isn’t an option.
Yes, it COULD be done if this was the only product on the market and we HAD to make it work.
Neither of these conditions are true though. Time and money are limited, and there is another product from the same supplier that will do it with far less struggle and a simple MQTT broker. Indeed, I’m told that ESPHome may even do direct peer-to-peer without needing an MQTT broker (although MQTT brings other future benefits).
Perhaps the protocol can be hacked to mimic something else async, but that’s no longer MQTT.
