- Sun Nov 13, 2016 6:26 am
#58069
Ok, thanks.
I'm in the process of trying to do my own 'mini mozzy' (mosquito) version of MQTT type of protocol for Esp_Basic anyway, so I would appreciate any advice or comments you (or anyone else) might have.
By taking just the cutie bits (QT) from the middle of MQTT and discarding the empty (MT) outside bits, it should be possible to create a self-sufficient client with Publish and Subscribe facilities without having to support a fat man-in-the-middle broker. This could be achieved by having the TOPIC include a list of its TARGET subscribers along with its payload of COMMAND & DATA, plus a Quality-of-Service control at the end (for specifying number of retries etc). So the broadcast message would look like:
[TARGETS][COMMAND][DATA][QoS]
I am not trying to re-create the sort of MQTT compliant brokers client that you were doing, merely a form of easy-to-use Esp_Basic intranet interaction (although there is no reason why Esp_Arduinos could not also interact with the Esp_Basic UDP nodes using the same simple protocal).
I would have loved to be able to use the ready-made MQTT functions you created - not least because of the ability to pass data to the functions - but they needed a Broker connection which I didn't know how to spoof, so I've been doing things the hard way from scratch.
The WORD() function can manage most of the parsing, but it has no way of relating word positions to the absolute character positions needed for string manipulations, so the simplests tasks - such as finding out how many words are in the string, or chopping off a word from either end (let alone from the middle) - all become big and bloaty.
For instance, an incoming ACKnowledged message requires snipping off the end QOS info and comparing the remaining TOPIC payload against a string list of sent TOPICS still waiting to be acknowledged, and if the acknowledged TOPIC is on the sent list, it needs to be snipped out from wherever in the list that it might be.
Imagine how quick and simple that could be with a suite of companion Word() functions for slicing and juggling the word strings, such as WordsCount(), WordFind("string"), WordInsert(n), WordDelete(n), WordSwap(n1,n2), WordsLeft(n), WordsMid(n1,n2), WordsRight(n), etc.
I'm not saying that to save myself any time or effort cos I've already done most of it the hard way, but I think it could be a worthwhile enhancement to Esp_Basic which others would appreciate.
Anyway, I've managed to muddle my way through one way or another up to now to get to this point (still plenty of learning to do yet though), but I doubt I'll be able to muddle my way through the final step alone - which would be an option to add a skinny BROKER for Keep-Alive persistent connections and Last-Will-&-Testament facilities. Not essential, but potentially worthwhile, especially if it might avoid the need for a wifi router!
I've yet to test the theory, but I think it might be possible for all clients to have their gateway address pointing to eg: a BROKER, such that all UDP messages automatically go to the BROKER by default (rather than a router) - in which case perhaps the wifi subnet may not even need a wifi router if the clients have static IPs assigned.
But perhaps additionally it may be possible for an Esp_Basic Broker to be able to act as a DHCP server?
I don't know enough about it to be sure, but I think a DHCP client request is just a type of UDP broadcast which is responded to by the DHCP server 'listener', so perhaps it might actually be possible for an Esp_Basic node to similarly respond as a DHCP server by sending out IP addresses from a list.
I'm not sure how much of all this is possible, but Esp_Basic is already doing the seemingly impossible, so it gives me encouragement to keep plodding on.
