Smalltalk › Squeak › Squeak - Dev

MQTT for Squeak?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

29 messages Options

timrowledge

Re: MQTT for Squeak?

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; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.

timrowledge

MQTT, Weather, Pi, ESP8266's and PlotMorph, oh my ( was Re: MQTT for Squeak?)

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IA: Illogical And

timrowledge

Re: MQTT, Weather, Pi, ESP8266's and PlotMorph, oh my ( was Re: MQTT for Squeak?)

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; [hidden email]; http://www.rowledge.org/tim
Never underestimate the bandwidth of a station wagon full of tapes.

timrowledge

Re: MQTT for Squeak?

In reply to this post by timrowledge

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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- He hasn't a single redeeming vice.

timrowledge

Re: MQTT for Squeak?

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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: LINO: Last In, Never Out mode

David T. Lewis

Re: MQTT for Squeak?

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

timrowledge

Re: MQTT for Squeak?

> On 01-02-2018, at 5:02 PM, David T. Lewis <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: EF: Emulate Fireworks

David T. Lewis

Re: MQTT for Squeak?

On Thu, Feb 01, 2018 at 05:08:48PM -0800, tim Rowledge wrote:

>
>
> > On 01-02-2018, at 5:02 PM, David T. Lewis <[hidden email]> 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

Eliot Miranda-2

Re: MQTT for Squeak?

> On Feb 1, 2018, at 6:22 PM, David T. Lewis <[hidden email]> 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 <[hidden email]> 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
>