Bump.
Starting to think more specifically about this. Current vision (initial direction of implementation) is to have MQTT Publisher and MQTT Subscriber devices independently, with one or more MQTTPUB/MQTTSUB instructions per device. Only one instruction can be enabled on a device at a time and each instruction will support up to 32 topics. You will be able to switch from instruction to instruction, but this will drop the connection to the broker and reopen it. In general, it is best to think in terms of one MQTT Publisher to one MQTTPUB, and same for subscribers.
If you need more than 32 topics in one direction, you can create another client/box pair.
I'm a little fuzzy on topic data. According to the spec, the topic message is application specific, and can apparently be just about anything. This presents the potential for significant effort if you want a "be all/end all" conversion facility built into the instruction. On the other hand, I'm guessing that 99% of what's out there is string data, so it makes more sense to publish all numerical values (V, N, D, R, etc) as string, and attempt to convert subscription data to numerical based on the output parameter (string to int or string to real). We will definitely allow strings as both both pub and sub parameters, so in the case that that the message is actually binary, you could publish to a string and then use STRGETB to extract the bytes to the relevant data type. What we are trying to avoid is overly complicating it: options for binary or string, byte swap, word swap, radix, byte/word/dword data sizes...etc. It gets ugly fast, and you still end up failing when the inevitable oddball comes along. I would rather it be easy for 90%, with a decent workaround for the rest.
Publishers will define an update rate, and then have the option of updating a topic only if it has changed. So you might set the update rate to 1 second, but only the topics that have changed since the last update will be sent. Although thinking about it, that would only work for numerical topic values...since it isn't practical to buffer the strings. I would expect much of the published data to be numerical though, so I want to support an event based update for those.
We are thinking that the MQTTSUB will have an optional DWORD parameter, where as a topic is updated, we'll set the corresponding bit. User can clear after he dispositions.
Not sure how to handle LWT. For publishers, that's pretty easy. Subscribers, it gets ugly-ish. I guess we could do something like a string parm for the last LWT we received, and an optional DWORD parm where we set bits for each topic we received LWT from. Since most LWTs shouldn't come in at the same time, that would be a solid 9 of 10.
Thoughts? We will be starting this soon-ish.
