I’m having all sorts of fun making some weather station and environmental sensors with assorted Pi and ESP8266 boards and I need a nice way to make the sensor nodes report back to base. Since the ESP8266 modules don’t run squeak (shame!) I’m using Arduino-c++ (blech) on them, and since the weather sensor code already existed in python (double-blech) I’m using that on the weather-pi board. I’ve been recommended to look at MQTT as a way to bind them all together and from what little sense I can make of the assorted stuff that googling had lead me to (good grief, so much acronym laden gibberish) it looks like it might do the job.
Googling for a squeak mqtt package has revealed nothing thus far so I’m now appealing to the list for any news.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- O! Plus! Perge! Aio! Hui! Hem! = Oh! More! Go on! Yes! Ooh! Ummm!
On Mon, Oct 24, 2016 at 8:18 AM, tim Rowledge tim@rowledge.org wrote:
I’m having all sorts of fun making some weather station and environmental sensors with assorted Pi and ESP8266 boards and I need a nice way to make the sensor nodes report back to base. Since the ESP8266 modules don’t run squeak (shame!) I’m using Arduino-c++ (blech) on them, and since the weather sensor code already existed in python (double-blech) I’m using that on the weather-pi board. I’ve been recommended to look at MQTT as a way to bind them all together and from what little sense I can make of the assorted stuff that googling had lead me to (good grief, so much acronym laden gibberish) it looks like it might do the job.
Googling for a squeak mqtt package has revealed nothing thus far so I’m now appealing to the list for any news.
Sven did a RabbitMQ client for Pharo, and maybe such non-gui stuff is close enough to Squeak to adapt... https://github.com/svenvc/docs/blob/master/neo/stamp.md
RabbitMQ has a MQTT adaptor... https://www.rabbitmq.com/mqtt.html
but this article notes some detractions depending on your use case... https://scargill.wordpress.com/2015/01/02/a-world-of-mqtt-on-esp8266/
cheers -ben
Thanks Ben,
On 23-10-2016, at 6:01 PM, Ben Coman btc@openinworld.com wrote: [snip]
Sven did a RabbitMQ client for Pharo, and maybe such non-gui stuff is close enough to Squeak to adapt... https://github.com/svenvc/docs/blob/master/neo/stamp.md
RabbitMQ has a MQTT adaptor... https://www.rabbitmq.com/mqtt.html
More than half of what I read there went so far over my head I couldn’t even see contrails. STOMP? Multiple plugins for a system that claims to be really simple and small? Argh! Maybe if I look into the code it might make some sense.
but this article notes some detractions depending on your use case... https://scargill.wordpress.com/2015/01/02/a-world-of-mqtt-on-esp8266/
Happily my use case is about as simple as I could imagine; several devices - probably one Pi and a bunch of ESP8266 nodes - publishing some small amounts of data every 15 minutes or so, and one recipient wanting to get that data to make pretty graphs and stuff. AIUI that means having a broker in the middle.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Change is inevitable....except from vending machines.
On 10/24/2016 01:12 PM, tim Rowledge wrote:
Happily my use case is about as simple as I could imagine; several devices - probably one Pi and a bunch of ESP8266 nodes - publishing some small amounts of data every 15 minutes or so, and one recipient wanting to get that data to make pretty graphs and stuff. AIUI that means having a broker in the middle.
Can your devices make HTTP requests?
I'd POST the data to something in the middle, and GET it from the rendering bit. (Or use the filesystem directly, if the rendering bit is conveniently located at the same place as the POST-receiving server.)
You might find the recently-published W3C PubSub draft of interest: https://www.w3.org/TR/pubsub/
Regards, Tony
On 24-10-2016, at 12:16 PM, Tony Garnock-Jones tonyg@ccs.neu.edu wrote:
On 10/24/2016 01:12 PM, tim Rowledge wrote:
Happily my use case is about as simple as I could imagine; several devices - probably one Pi and a bunch of ESP8266 nodes - publishing some small amounts of data every 15 minutes or so, and one recipient wanting to get that data to make pretty graphs and stuff. AIUI that means having a broker in the middle.
Can your devices make HTTP requests?
Oh definitely; Raspberry Pi are real computers. ESP8266 things are tiny and faintly Arduino-like but my goodness, people make them do amazing things for $3. I have one on my desk right now that just has a DHT22 temp/humidity sensor attached, running a simple REST server that returns JSON data. Squeak’s Json class talks to it perfectly well and of course a plain ol’webbrowser can simply connect to the IP address on port 80 to get the raw json text. It’s just code from https://openhomeautomation.net/connect-esp8266-raspberry-pi/
I'd POST the data to something in the middle, and GET it from the rendering bit. (Or use the filesystem directly, if the rendering bit is conveniently located at the same place as the POST-receiving server.)
I have to admit to having thought of doing the direct thing earlier but my interest in mqtt was piqued by discussions with a fellow Makerspace member. We had a kids drop-in-make over the weekend and one of the ‘classes’ was making pine derby cars. Some of the kids went all out to make them beautiful and I started thinking it might be nice to add LED head/tail lights. Then it occurred to me that for $3 we could add an ESP and control those lights from wifi. Then we got carried away and realised that for 50c you could add a piezo speaker and do horn and motor noises. And crash noises too I guess. Then it grew to having the sloped track equipped with a couple of electromagnets to hold the cars in place and release them simultaneously to start the race. Since the ESP does mqtt very easily (apparently!) it seems an obvious thing to consider.
There seems to be a lot of fun stuff one could do given an mqtt wotsit for Squeak, not to mention Scratch & Etoys.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim It said, "Insert disk #3," but only two will fit!
Oh, I’ve found a plain C version that might make enough sense to me. https://eclipse.org/paho/clients/c/ and code at https://github.com/eclipse/paho.mqtt.c
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim New: It comes in different colors from the previous version.
On Mon, Oct 24, 2016 at 10:12:42AM -0700, tim Rowledge wrote:
Thanks Ben,
On 23-10-2016, at 6:01 PM, Ben Coman btc@openinworld.com wrote: [snip]
Sven did a RabbitMQ client for Pharo, and maybe such non-gui stuff is close enough to Squeak to adapt... https://github.com/svenvc/docs/blob/master/neo/stamp.md
RabbitMQ has a MQTT adaptor... https://www.rabbitmq.com/mqtt.html
More than half of what I read there went so far over my head I couldn???t even see contrails. STOMP? Multiple plugins for a system that claims to be really simple and small? Argh! Maybe if I look into the code it might make some sense.
but this article notes some detractions depending on your use case... https://scargill.wordpress.com/2015/01/02/a-world-of-mqtt-on-esp8266/
Happily my use case is about as simple as I could imagine; several devices - probably one Pi and a bunch of ESP8266 nodes - publishing some small amounts of data every 15 minutes or so, and one recipient wanting to get that data to make pretty graphs and stuff. AIUI that means having a broker in the middle.
If I can believe what I a reading here:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Introduc...
then the actual protocol is straightforward, and could be implemented in Smalltalk directly. I have done a number of projects like that, mainly in Java but inspired by a design that was originally done in Smalltalk. If you put it together with classes to represent the messages that you want to read and write on the network, along with a bunch of unit tests to convince yourself that you did it right, then the result is simple and reliable and much better than anything you could implement with a VM plugin or FFI to a library that somebody else wrote.
I am assuming that that the "broker" is something that you downloaded from the internet and run on your Raspberry Pi, so that all you really need is a way for Squeak to read and write the messages that interact with the broker.
Dave
On 24-10-2016, at 5:59 PM, David T. Lewis lewis@mail.msen.com wrote:
If I can believe what I a reading here:
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html#_Introduc...
then the actual protocol is straightforward, and could be implemented in Smalltalk directly.
I’m hoping the claims for simplicity are correct! Certainly it can’t be horrendously complex because there just wouldn’t be room for it on a tiny thing like a ESP8266 otherwise. (And think for a moment - that’s a ‘tiny’ thing that has a 32bit 80MHz cpu with 64Kb of code ram and 96Kb of data ram and wifi. We would have killed for that much not so very long ago)
I am assuming that that the "broker" is something that you downloaded from the internet and run on your Raspberry Pi, so that all you really need is a way for Squeak to read and write the messages that interact with the broker.
Pretty much, at least for now. I suppose one might want a broker in squeak some day just because. I guess I’ll read more and see if I can recall anything about using sockets - a subject that has always confused me more than a bit.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LAG: Load and Garble
Hi Tim--
...I guess I’ll read more and see if I can recall anything about using sockets - a subject that has always confused me more than a bit.
I'd be happy to help if you like. Also, the WebSockets support in Squeak works fine. I use it heavily in the upcoming release of Context.
-C
-- Craig Latta Black Page Digital Amsterdam | San Francisco craig@blackpagedigital.com +31 6 2757 7177 (SMS ok) + 1 415 287 3547 (no SMS)
Progress so far -
Had fun loading up mosquitto & client stuff on a couple of Pi Got basics working - subscribe on one, publish on the other, woo-hoo! messages. Got equivalent client stuff on my ESP8266 (after loading arduino IDE and all the other gunge to support that) Re-wrote weather-sensor server python code (oh yuck. Have you actually seen python? ) to publish instread of using a RESTful server thingy. Load mosquitto on my mac-mini-server and use that as the broker.
It kinda-sorta works nicely, except after a while (not yet worked out how long) the weather client crashes because the attempt to open up a connection that has worked several hundred times decides to fail. The error message 'socket.gaierror: [errno -2] name or service not known’ doesn’t appear to lead to any readily comprehensible info.
Wild guess right now is something to do with one or other machine going to sleep?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: COMB: Straighten Wires
Important document for mqtt - http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
An actually intelligible spec, just for a change.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: SNARF: System Normalize And Reset Flags
And now I have my ESP8266 with DHT22 temp/humidity sensor publishing ok. Arduino c++ is really quite an amazingly unpleasant language. We need Smalltalk on these things!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim taffeta - Welsh goats cheese
Hey!
On 10/30/2016 12:37 AM, tim Rowledge wrote:
And now I have my ESP8266 with DHT22 temp/humidity sensor publishing ok. Arduino c++ is really quite an amazingly unpleasant language. We need Smalltalk on these things!
You can always help me with Spry! (sprylang.org)
It's becoming a kind of Smalltalk, and it can easily run in very small spaces. I know that Espruino (the tiny js interpreter that runs on ESP8266) needs a similar amount of RAM etc that Spry does.
In fact, I have already made an example where I almost made it all the way by wrapping Arduino libraries:
https://github.com/gokr/ardunimo
That shows an example in Nim linking happily with the Arduino libraries, but that means it would be trivially easy to expose it to Spry too.
regards, Göran
On 30-10-2016, at 3:07 AM, Göran Krampe goran@krampe.se wrote:
Hey!
On 10/30/2016 12:37 AM, tim Rowledge wrote:
And now I have my ESP8266 with DHT22 temp/humidity sensor publishing ok. Arduino c++ is really quite an amazingly unpleasant language. We need Smalltalk on these things!
You can always help me with Spry! (sprylang.org)
It’s interesting but I honestly don’t think I can cope with trying to learn another language at this point! My brain is both full and decaying. I think I need another dried-frog pill from the Bursar.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: DUL: Delete Utility Library
Progress can be reported on my Squeak MQTT client stuff. I have a client that runs asynchronously, so it lets you keep developing in your image. You can connect, subscribe with qos 0/1/2, publish with qos 0/1/2, unsubscribe, ping (for keep alive) and disconnect.
It’s quite interesting working away on stuff with little message coming in on the Transcript every now and then. I guess one could even use this to make a chat type application… actually, isn’t this pretty much Slack in Squeak? And every other message app?
T’ain’t finished yet; unacknowledged packets need to be retried and a helpful external api so a user can actually make sensible use of incoming data would be nice.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IAM: Increase Amperage Above Maximum
The MQTT client for Squeak is now in SqueakMap. Load Version14. Not Version13. Version13 is not the package you are looking for. 14 is the number of the package.
Read the class comment for MQTTClient.
T’ain’t completely finished; error handling needs improving (a lot) but that really needs some experience with using the package to decide how best to deal with it. I’m sure other stuff will come up too.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.
So I can now get weather sensor data from my weather station hardware (run by a Pi with some hacked up Python code) and several ESP8266’s (running Arduino code) via MQTT to my Pi3 (running Squeak, of course) and display the data in PlotMorphs.
Here’s the temperatures for the last 24 hrs -
That’s the guestroom, garage and outdoor temps. Note how the guestroom DHT22 sensor aliases because of it’s relatively low precision combined with a mistake in the Arduino code that casts the data to ‘int’ instead of leaving it ‘float'… gotta fix that.
IoT in Squeak is a good thing.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: IA: Illogical And
In a startling break with normal software practice I’ve documented the basics of the MQTTClient and its usage at http://wiki.squeak.org/squeak/63
As mentioned in the final section, I’d be very happy to read advice and suggestions for cleanly dealing with the ‘interesting’ errors that can make life with Sockets "So Much Fun ™ "
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Never underestimate the bandwidth of a station wagon full of tapes.
Thanks to John McIntosh the MQTT4Squeak package is now improved with working publishing! It worked in the past until I ‘improved’ it with a stupid bug.
Version 22 is the one you want. On SqueakSource and SqueakMap.
On the plus side the system monitoring a dozen or more environmental sensors has been running for nearly a year without a glitch. No publishing involved in that one though ;-)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- He hasn't a single redeeming vice.
More improvements to MQTTClient; thanks to John we caught an issue with QOS 2 publishing. And discovered that the mosquitto broker will actually pass on invalid UTF-8 topic strings (really - a single byte 192 was sent by someone on the test.mosquitto.org open broker), so we had to cope with such nonsense.
Version 23 on squeaksource.com/MQTTClient and listed in SqueakMap.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LINO: Last In, Never Out mode
On Thu, Feb 01, 2018 at 03:02:45PM -0800, tim Rowledge wrote:
More improvements to MQTTClient; thanks to John we caught an issue with QOS 2 publishing. And discovered that the mosquitto broker will actually pass on invalid UTF-8 topic strings (really - a single byte 192 was sent by someone on the test.mosquitto.org open broker), so we had to cope with such nonsense.
Version 23 on squeaksource.com/MQTTClient and listed in SqueakMap.
Thanks for the update. It looks like the unit tests require a running broker on host amtiskaw, is there a way that we might mock this out or similate it in the image? I suspect that a real broker would be a non-trivial thing to implement but some kind of fake broker to support the unit tests might not be too bad.
Dave
On 01-02-2018, at 5:02 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 01, 2018 at 03:02:45PM -0800, tim Rowledge wrote:
More improvements to MQTTClient; thanks to John we caught an issue with QOS 2 publishing. And discovered that the mosquitto broker will actually pass on invalid UTF-8 topic strings (really - a single byte 192 was sent by someone on the test.mosquitto.org open broker), so we had to cope with such nonsense.
Version 23 on squeaksource.com/MQTTClient and listed in SqueakMap.
Thanks for the update. It looks like the unit tests require a running broker on host amtiskaw, is there a way that we might mock this out or similate it in the image? I suspect that a real broker would be a non-trivial thing to implement but some kind of fake broker to support the unit tests might not be too bad.
Hmm, a good point that I hadn’t thought to address. Logically speaking it ought to be possible to connect instead to test.mosquitto.org or some other public broker. The problem then becomes making the broker send the appropriate packets, something I think I simply cheated on during initial testing. By installing the mosquitto package on my mac mini I also got a commandline client that I could use to trigger actions. Doing this right will probably involve some Actual Thinking. Oh dear...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: EF: Emulate Fireworks
On Thu, Feb 01, 2018 at 05:08:48PM -0800, tim Rowledge wrote:
On 01-02-2018, at 5:02 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 01, 2018 at 03:02:45PM -0800, tim Rowledge wrote:
More improvements to MQTTClient; thanks to John we caught an issue with QOS 2 publishing. And discovered that the mosquitto broker will actually pass on invalid UTF-8 topic strings (really - a single byte 192 was sent by someone on the test.mosquitto.org open broker), so we had to cope with such nonsense.
Version 23 on squeaksource.com/MQTTClient and listed in SqueakMap.
Thanks for the update. It looks like the unit tests require a running broker on host amtiskaw, is there a way that we might mock this out or similate it in the image? I suspect that a real broker would be a non-trivial thing to implement but some kind of fake broker to support the unit tests might not be too bad.
Hmm, a good point that I hadn???t thought to address. Logically speaking it ought to be possible to connect instead to test.mosquitto.org or some other public broker. The problem then becomes making the broker send the appropriate packets, something I think I simply cheated on during initial testing. By installing the mosquitto package on my mac mini I also got a commandline client that I could use to trigger actions. Doing this right will probably involve some Actual Thinking. Oh dear...
We are talking about test driven development here. No actual thinking required, trust me I read it in a book ;-)
But to be serious, you already have MQTTPacket>>encodeOn: for sending, and you have MQTTPacket class>>readFrom: for receiving. These do not require any external connections or sockets, so any kind of fake "server" that can respond by writing things like MQTTPacketConnAck over a stream should be sufficient to support stand-alone unit tests.
As far as figuring out the appropriate packets, cheating is absolutely the right thing to do. Figure it out with a real mosquitto server, then cut-n-paste into your fake one to do the same thing. Works a champ, I've done it a lot.
I have to admit that getting a fake server sorted out can be a pain, but it's worth a bit of extra effort because once you get it working it works forever without any apt-get or sudo or unix-foo annoyances.
Dave
On Feb 1, 2018, at 6:22 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 01, 2018 at 05:08:48PM -0800, tim Rowledge wrote:
On 01-02-2018, at 5:02 PM, David T. Lewis lewis@mail.msen.com wrote:
On Thu, Feb 01, 2018 at 03:02:45PM -0800, tim Rowledge wrote:
More improvements to MQTTClient; thanks to John we caught an issue with QOS 2 publishing. And discovered that the mosquitto broker will actually pass on invalid UTF-8 topic strings (really - a single byte 192 was sent by someone on the test.mosquitto.org open broker), so we had to cope with such nonsense.
Version 23 on squeaksource.com/MQTTClient and listed in SqueakMap.
Thanks for the update. It looks like the unit tests require a running broker on host amtiskaw, is there a way that we might mock this out or similate it in the image? I suspect that a real broker would be a non-trivial thing to implement but some kind of fake broker to support the unit tests might not be too bad.
Hmm, a good point that I hadn???t thought to address. Logically speaking it ought to be possible to connect instead to test.mosquitto.org or some other public broker. The problem then becomes making the broker send the appropriate packets, something I think I simply cheated on during initial testing. By installing the mosquitto package on my mac mini I also got a commandline client that I could use to trigger actions. Doing this right will probably involve some Actual Thinking. Oh dear...
We are talking about test driven development here. No actual thinking required, trust me I read it in a book ;-)
But to be serious, you already have MQTTPacket>>encodeOn: for sending, and you have MQTTPacket class>>readFrom: for receiving. These do not require any external connections or sockets, so any kind of fake "server" that can respond by writing things like MQTTPacketConnAck over a stream should be sufficient to support stand-alone unit tests.
As far as figuring out the appropriate packets, cheating is absolutely the right thing to do. Figure it out with a real mosquitto server, then cut-n-paste into your fake one to do the same thing. Works a champ, I've done it a lot.
+1
I have to admit that getting a fake server sorted out can be a pain, but it's worth a bit of extra effort because once you get it working it works forever without any apt-get or sudo or unix-foo annoyances.
The cost benefit ratio is high. No pain, no gain ;-)
Dave
On Sun, Oct 30, 2016 at 6:37 AM, tim Rowledge tim@rowledge.org wrote:
And now I have my ESP8266 with DHT22 temp/humidity sensor publishing ok. Arduino c++ is really quite an amazingly unpleasant language. We need Smalltalk on these things!
How small could we conceivably make the VM to fit on one of these...? https://www.arduino.cc/en/Products/Compare
For example the Mega... MCU: 8-bit 16 MHz AVR EEPROM: 4kB RAM: 8kB FLASH: 256kB
Current vm build product sizes... 4.1M phcogspurlinuxht/lib/.../pharo 4.8M sqcogspurlinuxht/lib/.../squeak 3.9M sqstkspurlinuxht/lib/.../squeak 1.2M sqstkspurlinuxhtminimal/lib/.../
That last one built without any internal nor external plugins. What areas might be attacked to feasibly improve on that, to the point it can meet rising hardware specs?
The 8 bit-ness is probably a killer though (??)
Maybe it would be better to port the VM to the ESP32... MCU: 32-bit 240 Mhz Tensilica Xtensa LX6 ROM: 448 KBytes for booting and core functions RAM: 520 KBytes FLASH: 4MB (per retail boards - 4 x 16 MBytes supported) https://www.sparkfun.com/products/13907 https://www.adafruit.com/products/3269 https://cdn-shop.adafruit.com/product-files/3269/esp32_datasheet_en_0.pdf
Those specs look like they are getting close enough to consider possibility. How small might an extremely minimal image be that just toggles an LED?
Hmmm.... I wonder where we might find someone both familiar with the MCU and positively inclined to Smalltalk? https://en.wikipedia.org/wiki/Tensilica
Some general ESP32 info... http://hackaday.com/2016/10/04/how-to-get-started-with-the-esp32/ http://hackaday.com/2016/09/15/esp32-hands-on-awesome-promise/ http://esp32.net/
cheers -ben
[1]
Hey!
On 10/24/2016 02:18 AM, tim Rowledge wrote:
I’m having all sorts of fun making some weather station and environmental sensors with assorted Pi and ESP8266 boards and I need a nice way to make the sensor nodes report back to base. Since the ESP8266 modules don’t run squeak (shame!) I’m using Arduino-c++ (blech) on them, and since the weather sensor code already existed in python (double-blech) I’m using that on the weather-pi board. I’ve been recommended to look at MQTT as a way to bind them all together and from what little sense I can make of the assorted stuff that googling had lead me to (good grief, so much acronym laden gibberish) it looks like it might do the job.
MQTT is indeed a very good easy protocol, it's simply publish/subscribe on topics - but it's designed for low bandwidth and IoT etc. I have written some articles on using MQTT with our Evothings (where I work) tool (making Cordova mobile apps using js).
Googling for a squeak mqtt package has revealed nothing thus far so I’m now appealing to the list for any news.
Mmm, I haven't hacked up an MQTT library - BUT... I did hack up a NATS library just a few weeks back.
There are several open source MQTT servers around (VerneMQ is nice) that are easy to fire up - and you also have WebSockets support (we use the Paho library).
Perhaps you could port Paho? Not sure if the code is nice enough to read.
regards, Göran
On 24-10-2016, at 12:57 AM, Göran Krampe goran@krampe.se wrote:
Hey!
Yo!
[snip]
MQTT is indeed a very good easy protocol, it's simply publish/subscribe on topics - but it's designed for low bandwidth and IoT etc. I have written some articles on using MQTT with our Evothings (where I work) tool (making Cordova mobile apps using js).
Googling for a squeak mqtt package has revealed nothing thus far so I’m now appealing to the list for any news.
Mmm, I haven't hacked up an MQTT library - BUT... I did hack up a NATS library just a few weeks back.
And NATS is …
So many acronyms, so little TOT[1]
There are several open source MQTT servers around (VerneMQ is nice) that are easy to fire up
Goodness me. Erlang? Session balancing? Reporting to Graphite? I just love how the VerneMQ github .md starts with ‘an extremely simple and lightweight’ and then shortly after has a long list of very much not simple nor lightweight features. I guess if one is digging into all this it probably all starts to seem terribly mundane after a while.
- and you also have WebSockets support (we use the Paho library).
Looks like we have WebSockets in 5.1; all the tests seems to be happy in TestRunner at least.
Perhaps you could port Paho? Not sure if the code is nice enough to read.
AFAICT it’s 2000 lines of JS, which may actually count as simple. It would help if I read JS of course, which I don’t.
Hey, I have an idea - Marcel! Isn’t this a perfect thing for one of your students to tackle? So much stuff at HPI seems to be working with things across the net. Just imagine the things that could be done with a squeak mqtt wotsit to talk from Etoys or NuScratch to, well, whatever.
tim [1] TLA Overload Tolerance[2] [2] Too many Letter Acronym -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Ne auderis delere orbem rigidum meum! = Don't you dare erase my hard disk!
From: tim Rowledge Sent: Monday, October 24, 2016 1:31 PM
On 24-10-2016, at 12:57 AM, Göran Krampe goran@krampe.se wrote:
Hey!
Yo!
[snip]
MQTT is indeed a very good easy protocol, it's simply publish/subscribe on topics - but it's designed for low bandwidth and IoT etc. I have written some articles on using MQTT with our Evothings (where I work) tool (making Cordova mobile apps using js).
Googling for a squeak mqtt package has revealed nothing thus far so I’m now appealing to the list for any news.
Mmm, I haven't hacked up an MQTT library - BUT... I did hack up a NATS library just a few weeks back.
And NATS is … [Ron Teitelbaum] http://nats.io/
squeak-dev@lists.squeakfoundation.org
-
Ben Coman -
Craig Latta -
David T. Lewis -
Eliot Miranda -
Göran Krampe -
Ron Teitelbaum -
tim Rowledge -
Tony Garnock-Jones