Most recent activity
-
MQTT with message retention is a pretty easy way to do this. Messages sent from Espruino’s TinyMQTT module have retention set by default. This is a good choice if you can easily have IP at both ends and you can have a slightly beefier box as a server. A Pi2 is fine.
If you are relatively new to all this NodeRed is a good choice because it has a UI to manage the design of the MQTT flows of data between your sensing devices and display, and add logic plus you can easily debug the MQTT messages flying around. However NodeRed doing any amount of work needs a beefier server, a Pi3 would be recommended. -
Thanks definitely same bug. Your solution is better as I couldn't be bothered to figure out the length calculations, though with a packet size of less than 127 I could have taken it easy:->
-
Thanks. Will switch a spare Pico to cutting edge for the lols
-
I'm working on an mqtt to bluetooth project. At the moment I'm using your espruinohub, Gordon, and nodered but I plan to switch to trying out nodered's contrib BLE module
-
Trying to use E.setConsole() on the Pico v2.04
I get:
Uncaught Error: Function "setConsole" not found!
Obviously I can use USB.setConsole(true) instead, but what if I want to set the console to null, which is in the documentation as
E.setConsole(null).?
(Incidentally, it took me a while to figure out that since my ESP8266 is on Serial1 my Pico's internet connection stopped working whenever I removed the USB connection, because (I assume) the console switched automatically to Serial1.)
-
I put some debugging code into a copy of TinyMQTT.js, and in each case with the problem MQTT messages the first byte of data (or sometimes the first two bytes of data) is/are missing.
Good receipt:
cmd 3 / 30:16:0:10:Coffeemaker/brewbrew
Bad receipt, it is received as two separate calls to the data handler in TinyMQTT (onDat):
cmd 3 / 30:0:0:0:
cmd 1 / 16:0:10:43:offeemaker/brewbrewWe can see that if these were received in a single call to onDat, the publish command would be good.
Looking at the code for TinyMQTT, I don't think the issue can be in there, it must be somewhere else - any thoughts on where to look next? Or any thoughts on a sensible workaround, maybe compelling the socket to wait a little longer for data somehow - but looks like that code is maybe built into the firmware in the net module.
In the meantime I have put in a horrible hack so that if it is a publish command (3) with a total length of less than 5 bytes - which should never happen in my setup - then it stores up to 4 bytes in state waiting for the next call, and prepends these to the second set of data it receives.
Here is the hacked replacement onDat function for TinyMQTT.js
function onDat(data) { var i; //var log="MQTT receiving "; if (_q.tmp != null) { //log += ' APPLYING STORED DATA '; data = _q.tmp + data; _q.tmp = null; } var length = data.length; var cmd = data.charCodeAt(0) >> 4; //log += " length " + data.length + " cmd " + cmd.toString() + " / "; if (cmd ===3 && length <5) { _q.tmp = data; //console.log(log + " STORING EXTRA DATA FOR NEXT TRANSMIT"); return; } //for(i=0;i<4;i++) { // log = log + data.charCodeAt(i).toString(16) + ":"; //} //log += data.substr(4,256); //console.log(log); //log = ""; if(cmd === 3) { var var_len = data.charCodeAt(2) << 8 | data.charCodeAt(3); var msg = { topic: data.substr(4, var_len), message: data.substr(4+var_len, (data.charCodeAt(1))-var_len) }; _q.emit("message", msg); } }All kinds of things could go wrong with this approach, especially if new messages are received in quick succession so I don't really want to live with it long-term.
-
I'm using TinyMQTT in a home automation project on a Pico + ESP8266.
About 20% of the time when handling new messages to subscribed topics, my message events fire but do not contain the topic or message, meaning I am unable to handle the message properly.
Subscribing using mosquitto_sub to check what is going on shows that the messages are definitely there and look normal, so this is an issue on the Pico side.
As a workaround I am sending an error back in the case of a null topic so that the UI can ask the user to try again but this is not satisfactory.
The fact it happens only a proportion of the time for identical messages suggests to me that it might be some kind of latency issue reading the data.
Anyone seen anything like this before with TinyMQTT? I am loth to switch to the much heavier MQTT, although I haven't tried it to see if it behaves better yet.
function MQTTmessage(msg) { console.log("MQTT message " + msg.topic + ":" + msg.message); if (msg.topic.endsWith("/topic1")) { //doSomething(); } if (msg.topic.endsWith("/topic2")) { //doSomethingElse(); } if (msg.topic == "" || msg.topic == null) { //in this case msg.message is also empty throwError(null, "null message received - please try again", false); }
By “it “ what do you mean?
There is a tutorial here which I started with. https://www.espruino.com/BLE+Node-RED
Here’s a simple breakdown of the general steps you need, I won’t have time (sorry!) to spell them all out in detail
1) you need an MQTT broker, sounds like you have that in aedes, but people often use Mosquitto
2) you need a BLE to MQTT bridge to get messages from Bluetooth to MQTT, for this you could consider Gordon’s EspruinoHub which also by the way has full instructions starting from scratch for running on a Pi.
3) you need a program running on the Bangle which is advertising data on BLE - I imagine it broadcasts battery by default so you could just start with that
4) you configure NodeRed to subscribe to MQTT messages coming from the Bangle and/or send messages to the Bangle take actions based on them. A good place to start is installing NodeRed’s dashboard UI and use the dashboard for testing.
If you are a decent programmer you can skip NodeRed and build your own program on the server to subscribe to the MQTT messages and respond directly.
It is more complicated to handle sending data to the Bangle, and advertising is by far the simplest mechanism.