HP Microserver N40L RAID errors

 

The HP MicroServers (N36L/N40L/N56L) were bargains when they first released costing around £100 after cashback. Although their CPUs are pretty slow by modern standards they still make good NAS servers as they take standard 3.5" SATA drives.

I've got one running Windows 10 Pro from an SSD in the CD-ROM bay, leaving all the bays free for data drives running in AHCI (non RAID) mode. I recently upgraded from 2TB to 4TB data drives to give myself a bit more backup space. 

The lazy way to upgrade is to pull a drive, replace it and then let the array rebuild. Repeat this process for each drive and at the end you can expand the volumes. During this process though the data is at risk because should a remaining drive fail, everything is lost. The drive bays on these servers aren't hotswap so they do need to be powered off first.

The correct expansion method is to add a new disk to the storage pool, prepare the old drive for removal and then finally remove it. A USB caddy is a good way to temporarily add an extra drive. My advice is to add some USB3 ports via a PCIe card else you'll be waiting for days at USB2 speeds.

At first I tried the lazy method as this server only contains backup data but had problems rebuilding. I had 4 new drives and each one failed with multiple I/O errors, dropping offline and machine lockups. Checking the drives on another PC found no errors on the drives and they worked fine.

After a lot of experimentation I found it to be a problem with the default Microsoft AHCI driver and the AMD chipset in this server. Despite AMD saying to use the default driver with Windows 10, it actually works reliably with their amd_sata.sys version 1.2.1.402 driver.

Home Assistant control of Mitsubishi MCFZ-A24 WV A/C - Part 3

With the hardware built and Tasmota compiled the final piece is to link it up to Home Assistant. 

I am using the built-in MQTT broker and Tasmota is configured with the Home Assistant address. I've added a dedicated user name and password for Tasmota devices via the MQTT configuration.

Adding the climate control to Home Assistant is relatively easy, although it's not automatically discovered as it is with other ESP8266 firmware projects. To add the climate component manually edit the configuration.yaml file and add:

climate:

  - platform: mqtt

    current_temperature_topic: "tele/tasmota_xxx/SENSOR"

    current_temperature_template: "{{ value_json['BME280']['Temperature'] }}"

    temperature_unit: "C"

    name: Conservatory

    modes:

      - "off"

      - "cool"

      - "heat"

      - "dry"

    swing_modes:

      - "on"

      - "off"

    fan_modes:

      - "high"

      - "medium"

      - "low"

    min_temp: 16

    max_temp: 31

    initial: 18

    power_command_topic: "cmnd/conservatoryac"

    mode_command_topic: "cmnd/conservatoryac"

    temperature_command_topic: "cmnd/conservatoryac"

    fan_mode_command_topic: "cmnd/conservatoryac"

    swing_mode_command_topic: "cmnd/conservatoryac"

    precision: 1.0

The first section is relatively straightforward and configures the climate control with the available functions and where to get the temperature data. The second section was more difficult to work out because I had to try and associate the actions from the control with the IRhvac function of Tasmota. I try not to use custom controls where possible to avoid upgrade problems in the future. I initially struggled to find something that would work with the built-in Home Assistant functions but did get some inspiration from the Home Assistant forum.

What seems to work quite well is having the climate control publish to a temporary topic in MQTT and then using that to trigger an automation using automations.yaml. I need to finish off passing through the swing modes to IRhvav but I don't often use that setting.

- id: ac-control

  alias: AC Control

  trigger:

    platform: mqtt

    topic: cmnd/conservatoryac

  action: 

    - service: mqtt.publish

      data_template:

        topic: cmnd/tasmota_888715/IRhvac

        payload: >

          {% set pwr = 'on' if states.climate.conservatory.state != 'off' else 'off' %}

          {% set mitmode = 'cool' if states.climate.conservatory.state == 'off' else states.climate.conservatory.state %}

          {"Vendor":"MITSUBISHI112","Power":"{{pwr}}","Mode":"{{mitmode}}","FanSpeed":"{{state_attr('climate.conservatory', 'fan_mode')}}","Temp":{{state_attr('climate.conservatory', 'temperature')}},"SwingH":"Off","SwingV":"middle"}

  mode: single

Putting it all together, the card looks nice on the dashboard and is easy to use. Extra options are available from the ⁝ icon.

Pushing one of the icons on the climate controls results in a "beep" from the A/C and a log entry in the Tasmota cosole.

Home Assistant control of Mitsubishi MCFZ-A24 WV A/C - Part 2

In part 1 I described how I decoded the IR signal from the original remote and modified Tasmota to send commands the A/C unit was happy with. As IR is one way, I also wanted to read the room temperature so I wanted to add a BME280 module. These are quite nice as they can read temperature, pressure and humidity over an I2C connection.

The whole point of this project was to try out new things and building a circuit with perf board isn't something I'd done before. My first attempt was bit messy but the second was OK and fitted nicely into a small project box. I used a standard 2N2222A transistor to drive the LEDs, which are just generic 940nm ones from eBay.

The ESP-01S modules that I used doesn't break out many GPIO pins to the header but Tasmota let's you re-assign pins. The ESP chip has a few constraints and won't boot if certain pins are pulled low at power-on but with a bit of trial and error (although it is well documented) I found a working combination of pins.

Originally I put the BME280 into the same enclosure but I didn't take into account how much heat the ESP8266 and AMS1117 3.3v voltage regulator give off, which skewed the readings. To mitigate this I put the sensor into it's own box (with some small vent holes) and added an interconnect cable. I2C is really meant for short PCB connections but a 30cm cable seemed to work OK. There are better enclosures for temperature sensors but this will have to do for now. I'm also experimenting with MP1584EN voltage regulators as they should run cooler.

I'd already generated a custom firmware build for the IR sender so I re-compiled it again to add in support for the sensor. Usually it's included in to the tasmota-sensors binary but that is separate to the tasmota-ir binary due to the limitations of the ESP module.

Once all fitted together it looks quite neat, although it does need a reasonable view of the A/C in order to reliably send commands.

In part 3 I'll show the Home Assistant configuration.

Home Assistant control of Mitsubishi MCFZ-A24 WV A/C - Part 1

I was looking for things to automate with Home Assistant and the air conditioning in the conservatory should have been an easy win. The A/C is around 15 years old but has the "CN105" connector which on many models allows for bi-directional communication. I built a cable and compiled mitsubishi2MQTT. Unfortunately I didn't get any response from the A/C so I guess it either requires a different protocol or just doesn't support serial control.

My next plan was to use infrared as that's how the standard remote operates. Air conditioning IR remotes work a bit differently to remotes used for TVs and set top boxes. Instead of sending individual commands, they send the complete state the A/C should be in (mode, fan speed, temperature etc) on every keypress. To control the A/C this means generating the IR codes along with a CRC instead of a simple look-up table.

Luckily this functionality is all built into Tasmota. I built myself a breadboard IR circuit that could be driven by an ESP8266. I tried all the different IR protocols supported by Tasmota but got no response. Having never built an IR sender before I had no idea if the problem was the circuit or the protocol. Therefore the first task was the prove the circuit so I found some Panasonic codes and was able to control my TV. The range was poor but easily improved by changing the resistor and therefore increasing the brightness of the IR LED. I now had a working IR so the next step was to capture and analyse the signal sent by the Mitsubishi remote to see if I could reproduce it.

I found an IR receiver from a scrap digital TV box and connected that to a Raspberry Pi. I used this guide for inspiration as the IR decoding tools in Raspbian weren't able to read the codes. Capturing button presses from the remote and then decoding the result gave me codes like these: 

1100010011010011011001001000000000000000001001000001000011100000010110000000000000000000000000000000000001000110 (on)

1100010011010011011001001000000000000000000001000001000011100000010110000000000000000000000000000000000001111010 (off)

Each code was a consistent 112 bits long and I could see how different remote settings were changing bits in the code. I figured out how to send raw codes with the Tasmota IRSend console command and I was rewarded with a "beep" from the A/C. Progress!

At this point I was confused why the MITSUBISHI112 protocol in Tasmota didn't work as it seemed very similar. Looking at the source code I found Tasmota uses the IRremoteESP8266 library. I eventually figured out the MITSUBISHI112 protocol assumes the A/C vanes have both horizontal and vertical controls. On the MCFZ A/C only vertical vane controls are available and if the horizontal vane bits are set to anything other than 0000 then the command is ignored. I modified the code to add kMitsubishi112SwingHOff, compiled a new firmware binary and finally had IR control working.

With a working prototype I could now build a PCB, add a temperature sensing and integrate with Home Assistant.