Table of Contents

About

The Amiga can be conveniently controlled via a WeMoS D1 Mini board in order to either pull data from the Amiga (such as CPU temperature) or turn the Amiga on or off via triggers such as Amazon Alexa.

The designing iLO devices project relies on a battery to sustain a Raspberry Pi when the power is off. However, a better approach is to create a circuit parallel to the entire power supply in order to draw $5V$ regardless whether the computer is on or off.

Another approach is to use the $+5V$ VSB power line from the ATX power supply itself, however the line is not meant to support heavier loads and that may have consequences on the other pins of the power supply itself.

The following modification to a towerized Amiga 1200 will consist in the following steps:

The project assumes that the Amiga has a Mediator board and is towerized using a PC case.

Requirements

Adding the Parallel Circuit to the Power Supply

The power supply modification is needed to power the WeMoS board even when the Amiga is powered off. The modification adds a secondary power converter and step down that converts $220-110V$ to $5V$ using a small module (internally, a Wheatstone bridge converting alternating current to direct current plus a step down circuit to $5V$) connected to the mains pins and with two leads for $5V$ and $GND$ leading out of the power supply box.

One part of the power plug jacks is mounted on the power supply case itself by drilling a small hole to fit the jack as shown in the image above. The leads outside of the power supply box that are not connected will be soldered to a micro USB cable in order to power the WeMoS.

Designing the Pass-Through and GPIO Switch

This is a very easy to understand circuit that uses a 2N3904 to make contact between PS_ON and PS_ON / GND whenever a $3.3V$ current is supplied to a GPIO pin on the WeMoS board. Furthermore, PS_ON and PS_ON /GND are additionally connected to the PC tower power switch such that the computer can be turned on using the standard power button as well. 

To PC tower Case Switch
   <---+------------------------------+---------+---------> to motherboard PS_ON
                                      |         |         
                                      |         |         
                                      C         |         
                                    |/           /        
             +-- GPIO +---+/\/+----B|  2N3904   + Case    
             |           460kOhm    |\          | switch  
             |                        E         |         
             | GND                    |         |
             |                        |         |
   <---+-----+------------------------+---------+---------> to motherboard PS_ON / GND
To PC tower Case Switch               |
                                      - GND

The assembled result looks like the very small PCB on the right in the following image:

where:

The pass-through switch has six Dupont cables leading to:

Programming the WeMoS D1 Mini for GPIO Toggling

Using a PC or a Mac, the WeMoS can be connected to the USB port and programmed using the Arduino IDE. The sketch to be programmed can be programmed with a boilerplate pin toggling template.

After the WeMoS has been programmed, the functionality of the sketch can be tested using a standard voltmeter and an MQTT client such as mosquitto_pub. For instance, the following message would be sent to the MQTT server that the WeMoS subscribes to: 

{ "pin": 8, "state": "on" }

via: 

mosquitto_pub -h MOSQUITTO_SERVER -t WEMOS_TOPIC -m '{ "pin": 8, "state": "on" }'

which would make the WeMoS set the GPIO pin 8 (as printed on the board) to logic HIGH ($3.3V$). Then, using a voltmeter, the difference between the GPIO pin 8 and the pin marked on the WeMoS GND can be measured - it should be approximately $3.3V$.

If the tests succeed and the WeMoS properly re-connects to the WiFi network and subscribes to the MQTT server, then the board can be assembled inside the Amiga.

Coupling with Node-Red

Assuming that the command-line tests succeed, the project would be done, however now that the WeMoS responds to messages on the MQTT bus, it is convenient to find a more humane interface to interract with that will switch the Amiga on or off. Whilst, the designing iLO project uses OpenHAB, for this project Node Red is used.

A sample Node Red flow would be the following:

where: 

// MQTT topic to send the message on
msg.topic = 'esp/amiga';
msg.payload = {};
msg.payload.pin = 8;
msg.payload.state = "on";
 
return msg;

where esp/amiga is the topic to broadcast the message on for MQTT,

This may seem counter-intutive: once Alexa is told to "turn Amiga on", the signal flows from the "Amiga" node to the "Amiga On" node where a message is generated to be sent to the MQTT bus. The message sent by "Amiga On" contains the "pin" and "state" keys that the WeMoS will intercept and set the GIO pin 8 to HIGH. However, some confusion may arrise why the message is split after the "Amiga On" into two - first sending a straight-through signal and then delaying the second signal for $250ms$ and then sending a message to set the GPIO pin 8 to LOW.

This can be explained by looking at the basics of digital pins, where the push-switch for the Amiga Mediator actually generates a logic 1 instead of "just making contact between pins" - quite so, since holding down the Amiga power switch will achieve absolutely nothing until the button is also released.

Imagine the signal as a digital 1 square signal where the period $T$ can be as narrow as a few nanoseconds $t_{p}$ and as long as whatever much time $t_{r}$, the difference thereof between $t_{r}$ and $t_{p}$ representing the period of the signal and also the duration of the button press: 

^ voltage
|
|   
|  +-------------+ . . 5V
|  |             |
|  |             |
+--+-------------+------->
   ^\           /^      time
   . ----------  .
   .      T      .
  press         release

In effect, if the power button were to be pressed and held down, nothing would happen until the button were to be released such that the period $T$ does not matter.

The first message sent to the WeMoS would be: 

{ "pin": 8, "state": "on" }

and would represent $t_{p}$, the moment when the button is pressed.

Conversely, the second delayed message would be: 

{ "pin": 8, "state": "off" }

and represents $t_{r}$, the moment when the button is released.

The same proceedure takes place when the Amiga turns off and it is important to note that setting the GPIO pin to HIGH does not imply "turning the Amiga on" but rather "start pressing the PC power button".

Closing Notes