Workaround for Joplin-server encrypted notes sync error

Joplin-server is a nice solution to sync multiple Joplin instances. In fact, you can even use it to sync only a subset of your notebooks to certain devices by providing different user accounts for those devices and using the notebook-sharing functionality in Joplin-server.

I did find in Joplin-server that syncing shared encrypted notebooks didn’t always succeed in sharing the master keys. One workaround if you own all the accounts, of course is to use a single master key with a very strong password.

To achieve this:

  1. Close your secondary Joplin client with the option Joplin->Settings->Sync (advanced)->’delete local data and re-download from sync target’;
  2. Connect to the postgresql database with the credentials that you used to set it up (e.g. check your .env if you used docker-compose). Go to the table ‘items’;
  3. Inspect the stored master keys, e.g. [...] content LIKE '%activeMasterKeyId%'(should only hit for ‘info.json’);
  4. Copy the value of the content and content_size fields of your primary account to those of your secondary account (you can determine primary and secondary by comparing the keys with those found in Joplin->Settings->Encryption);
  5. On the secondary Joplin system, edit the database in ~/.config/joplin-desktop/database.sqlite and also insert the primary master key data into table ‘settings’ -> field ‘syncInfoCache’;
  6. Restart your secondary Joplin, and it will download your notes and use the right master key. No more yellow warning banners in the apps.

Home assistant temporary scenes based on area_id

When using lights in automations to inform the users (e.g., using light.turn_on with the flash property), you’ll want to reset the lights to their previous state after the automation is completed. In case of Hue lights it doesn’t seem to work to expand() the automatically-added light groups. What I’ve opted for instead, is to retrieve the entity_ids from an area and use this as input for scene.create (which requires, of course, that you assign each of the Hue lights to an area inside Home Assistant, which I find this an acceptable trade-off).

Since I use Node-RED for my automations, I do the following:

  • Template node, containing:
    {% for entity in expand(area_entities('<NAME_OF_YOUR_AREA>')) | selectattr('entity_id', 'match', 'light.*') %}
    {{ entity.entity_id }}{%- if not loop.last %}, {% endif -%}
    {% endfor %}

    (You can let it output to the payload field or another field of your choosing.)
  • Service call node, calling scene.create with data { "scene_id": "before", "snapshot_entities": $.payload }
  • <your light operations, such as hue.hue_activate_scene, flashing lights, etc.>
  • Service call node, calling scene.turn_on with data { "entity_id": "scene.before" }

Home assistant, localtuya, and Petoneer Nutri Mini

I can confirm that the Petoneer Nutri Mini (a.k.a. Pettadore Nutri Fresh) can be controlled via the local Wi-Fi by Home Assistant. This can be achieved using the localtuya integration, which means that you have no dependency on the cloud.

Steps:

  1. Setup your device with the Tuya IoT cloud in order to get the required API tokens that you need. All these steps are well described in the tuyaapi documentation.
  2. Add localtuya to your installation, for example via the HACS approach (as it’s not in the main integrations repository).
  3. Once you setup localtuya, it will find devices on your network. If you have the IoT in a different VLAN, you might need to directly provide the device’s IP address to localtuya.
  4. Localtuya will interrogate your Nutri Mini for its capabilities. It is important that you don’t have other tools (like a tuya-cli) with an open connection to your device (it supports only one connection at a time).
  5. Then the important part: which property IDs map to which device function? I didn’t enumerate them all, as for me the ‘express feeding’ capability was the only one of interest. For example, 103 is the device beep when feeding. However, the important one is ID 3, which controls express feeding. Use device type switch.
  6. Once you’ve added this ID (3) to Home Assistant, you will see a toggle (boolean) entity being added. If you switch this toggle from off to on, it will dispense food.
  7. Since the toggle is by default on true, it takes two steps to dispense (on->off, off->on). I’ve not tried to deep-dive if this can be changed, but simply created a script:
- express_feeding:
    mode: queued
    max: 10
    sequence:
      - service: switch.turn_off
        target:
          entity_id: switch.feeder
      - service: switch.turn_on
        target:
          entity_id: switch.feeder
      - delay: 3

Now you can call this script in your automations to dispense food at conditions such as pets being indoors, specific times, etc.

Update fall 2022: I found that DPS 14 is for whether the device is empty.

Switching on IPMI devices using Home Assistant

One of the systems on my home network can be switched on/off using IPMI. Since Home Assistant is running 24/7, it would be useful to be able to power toggle this system straight from Home Assistant.

There is currently no add-on or integration that can perform this task. In the meantime, the following hack provides a workaround.

configuration.yaml

shell_command:
  ipmi_install_and_trigger: "which ipmitool >/dev/null 2>&1 || (apk update && apk add ipmitool); ipmitool -H <INTERNAL_IP_ADDRESS> -U admin -P <PASSWORD> chassis power on"

Lovelace

[...]
    cards:
[...]
      - name: 'install ipmitool and trigger <SERVER_NAME>'
        type: button
        tap_action:
          action: call-service
          service: shell_command.ipmi_install_and_trigger
        show_icon: true
        show_name: true

You can install this lovelace card in your existing dashboard by using the raw configuration editor and pasting the above in the respective section.

Fixing Wi-Fi connection issue Honeywell Evohome with Ubiquiti UniFi access point

I found that my Honeywell Evohome thermostat would not properly connect to my (IoT) Wi-Fi SSID. Looking in the logs of the UniFi controller, it appeared that the thermostat was ignoring the DHCPOFFER it received from the DHCP server in the controller. The thermostat interface indeed showed that it could not get an IP address.

The solution that worked for me was to disable the BSS Transition option in the UniFi controller:

(Note that I earlier already disabled 5Ghz and enabled legacy support for this SSID. These settings might help as well, but were not the solution in this case.)

After this BSS Transition change, the thermostat was able to connect immediately. I confirmed that from two otherwise identical SSIDs, the thermostat could only connect to the one with BSS Transition disabled.