SstHttpClient>get:streaming: with streaming true

[Louis LaBrunda]

Hi Gang,

Does anyone have any examples of SstHttpClient>get:streaming: with streaming true?  It is supposed to answer a stream.  It answers a SstStreamedByteMessage, which isn't exactly a stream.  When it tries to #listen: on its own instance #inputStream it blows up because #inputStream is an empty string.  I'm probably doing something wrong but some sample or test code would really help me understand what is going on.

Lou

[Johan Brichau]

Hi Louis,

The SstStreamedByteMessage supports asynchronous handling of the response. The following snippet should work and write the streamed response to the transcript.

Does this help you get further?

response := httpClient get: url streaming: true.

response inputStream

listen: [ :chunk | Transcript show: chunk asByteArray asUnicodeString ]

onError: [:e | httpClient shutDown. Transcript show: ‘---Error receiving: ‘, e description ]

onDone: [ httpClient shutDown. Transcript show: ‘---End of response---' ]

[Louis LaBrunda]

Hi Johan,

YES!!!  This is just what I needed!  The data is JSON, so I can put STONReader code in the listed block to parse and save it.  Many thanks.

Lou

[Johan Brichau]

Hi Louis,

Yes, but mind that a streaming http server will produce chunks that each will not parse as complete JSON. So, if you want to do 'streaming parsing', that will require a conversion from the 'pushed stream events' of the http stream to the 'stream pull' implementation used by NeoJSONReader. In essence, you cannot parse each chunk as valid JSON. It boils down to having one process put the events on a stream and have another process pull it from that stream when there is something available.

I'll look a bit for a example of how to do that.

[Louis LaBrunda]

Hi Johan,

Thank you.  An example will be helpful.  The data I'm expecting tends to be small, so it would probably work most of the time.  A bug just waiting to jump out!

Lou

[Norbert Schlemmer]

Hi Louis,

 

Why do you need the "streaming: true" setting when you expect a "small" JSON structure as a response? Or is it not so "small" after all?

 

br

Norbert

 

Louis LaBrunda <loulab...@gmail.com> hat am 06.11.2025 17:28 CET geschrieben:

--
You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/1def4f9c-3835-425d-87e2-3a1c9aad56c7n%40googlegroups.com.

[Louis LaBrunda]

Hi Norbert,

I was planning on posting some background information today, so, I will do it now and it should answer your question.  I have an AcuRite Iris (5-in-1) Weather Sensor with Rain Gauge, Wind Speed, Wind Direction, Temperature and Humidity (06004M) weather station that I want to access its weather data from my Raspberry Pi computers.  The weather station broadcasts its weather data as a radio signal at about 433 MHz.  It periodically transmits its current weather values as a small JSON object.

I also have an RTL-SDR Blog V4 R828D RTL2832U 1PPM TCXO SMA Software Defined Radio (Dongle Only).  It is a USB radio receiver with an antenna.  It can be plugged into a USB port and receive all kinds of radio signals with the proper software.  In this case the software is rtl_433.  rtl_433 gets the radio signal from the RTL-SDR receiver and with its built in protocols (there's one for my weather station) can save or pass on the data.  In this case I choose to have the data passed on via a streaming socket.  One of my Raspberry Pis (with VA Smalltalk running on them) will have the RTL-SDR receiver connected to it and rtl_433 passing the data on via the streaming socket.

My other computers, mostly Raspberry Pis but also my Windows VA Smalltalk development machine, can get the weather data from the Raspberry Pi running rtl_433 and its streaming socket.  That is the code I'm working on now.  There are two rtl_433 socket endpoints that make sense for me to use: /events - that streams chunks and /stream that just streams.  The frequency of the data transmitting (not the 433 MHz but how often new values are transmitted) varies, I think based upon changing weather conditions like wind speed changes.  The data seems to be small JSON objects starting with "{" and ending with "}" and separated by CrLf.  I think there can also be just CrLfs, used as a heartbeat or keep alive signal.

I'm trying to decide between two approaches.  1) After getting the data into a ReadStream, use #nextLine to get each JSON object and give it to STONReader to turn into a dictionary.  I would skip empty lines as I think the STONReader doesn't like them.  2) Try to feed multiple whole and/or partial chunks into the STONReader, catch and ignore the errors, in the hope that new data will show up soon.  A variation on this would be to catch the error of a partial chunk and wait for the rest of it, but that makes #1 look easier.

I'm open to any and all suggestions.

I have a lookup table with the weather data that when new JSON objects come in, I will run their keys and values and add or replace the values in the weather data lookup table.  I can then get the most up to date values from the lookup table.  

What am I doing all this for?  My clock program displays some weather data but it gets it from the internet, this will be from my backyard.  My other program has a motion sensor that turns on some blinky lights to scare off the dear.  But in times of high wind, the sensor turns the blinky lights on because of the movement of a near by tree and not any dear.  So, knowing it is windy, I can reduce the number of times the blinky lights are turned on.  The weather station also detects if it is raining.  If it is, the program that runs the lawn sprinklers, won't water the lawn. 

Lou

[Norbert Schlemmer]

Hi Louis

The WeeWX project can retrieve data from such a device and transmit it via MQTT. Perhaps this will help you.

https://github.com/weewx/weewx

br

Norbert

 

Louis LaBrunda <loulab...@gmail.com> hat am 07.11.2025 15:53 CET geschrieben:

To view this discussion visit https://groups.google.com/d/msgid/va-smalltalk/a5a78540-318f-4841-bdd4-813194b08d1cn%40googlegroups.com.