Calls my homemade Pico environment monitor API to fetch information, and shows them in a nice MUI GUI :)

This is what is looks like in OS 3.2:

Goals

I had a few goals with this project:

• Have a way for my Amiga to view temperature and other environment data in a nice way.
• Experiment with MUI for creating nice Amiga GUIs.
• Take testing (mostly unit testing) as far as possible on a real Amiga.
• Use modern CI/CD to test and release using Github Actions.

Requirements

OS 3.x (m68k)

• TCP/IP stack like Roadshow to provide BSDSocket.library
• MUI, at least 3.8
• PNG datatype. (included in OS 3.2). Might change to an ILBM or similar image to improve compatibility later.

OS 4 (ppc)

• Internet connection set up… duh… (at least access to your local network)
• MUI version 5

Usage

Before you run the AmiEnvMon program, make sure the correct IP is set in the Settings program. Currently the fetching of the data from the server will never time out, so the IP should be correct. This might be fixed in a future release.

ARexx commands

AmiEnvMon provides the commands temperature, eco2 and humidity to get the corresponding data as strings in your ARexx scripts. They all take zero arguments. Why even have this? I wanted to experiment with how one would add ARexx commands to a MUI program :)

Example program:

/* Simple environment monitor example */
options results
ADDRESS 'AMIENVMON.1'

'temperature'
temperature = result

'eco2'
eco2 = result

'humidity'
humidity = result

say 'Temperature is ' temperature ' celsius'
say 'ECO2 levels ' eco2 ' ppm'
say 'Humidity is at ' humidity ' %'

About the coding style

NB: The filenames and minor naming will probably change.

My coding standard here and other places are based upon many factors:

• My experience in spare time programs, work (professional work has mostly been higher level work than C) etc. over many years.
• Me disliking a lot of other coding styles I have read in the C world.
• Reading various books on C and seeing different coding styles

It may be a bit unconventional at times, but I like it this way. My rules are as following:

• Private, local- or standalone functions are camelCase.
• Variables and parameters are snake case like Rust. (example: my_variable)
• Some interfaces fall naturally into being components. Example: a ChatMessage component system that work on Chat data. These functions will be a special case, example: ChatMessage_InsertMessage. This is in a way to “emulate” logical components.

Love it or hate it, I think it makes programs more easy to reason about and read :)