Blog

Window Notification

2023-07-30T00:00:00Z

I generally don't like AC, as I live in Michigan and I would like to enjoy the heat while it's here. This does not mean I like to go upstairs and have it feel like I've opened up an oven's door. As an attempt to reduce that uncomfortable feeling, I want to set up an automation to notify me when I should open the windows.

To do this there's two pre-reqs:

A Thermostat
A way to get the outside temperature, I use the National Weather Service integration

Hardware #

While I do own a Nest, there's a two problems:

It requires the cloud, which I try to avoid
It's downstairs

Instead, I bought a Tuya compatible thermostat from Amazon. I also use the HACS Plugin Local Tuya to communicate with my Tuya devices directly instead of through the cloud

Be aware: This thermostat with Local Tuya outputs in C, there is extra HA configuration to get it as F.

Setup #

Note #1: I recommend connecting your Tuya API with Local Tuya. This generally makes the install process a little easier as it prefills some of the required fields, like Local Key.

Note #2: In the past month moved all my IoT devices into their own VLAN, which doesn't support the Tuya API due to the discovery being blocked, I'm editing this section to have more detail. (2023-12-28)

The process is the same as adding any device through Local Tuya. That being entities are not fun, as generally it's a slightly informed guessing game. There are three values: two numbers and a boolean.

Device ID (IoT Tuya) #

Login to https://auth.tuya.com/
Sidebar, Cloud -> Development
Table, Open Project
Top bar, Devices
Table, find Sensor
Copy Device ID

Local Key (IoT Tuya) #

Login to https://auth.tuya.com/
Sidebar, Cloud -> API Explorer
It should load into IoT Core, else change in top left dropdown
Sidebar, Device Management -> Query Device Details
Paste Device ID + Submit (hidden by a cookie warning)
Find local_key key in the JSON dictionary it returns

HA Local Tuya Add #

Name: {anything}
Host: {static_ip}
Device ID: {saved from earlier}
Local Key: {saved from earlier}
Protocol Version: 3.3
Submit

Temperature #

The raw value is in C and has a scaling factor of .1, The number will be an integer (no decimals) and will have three digits

Name: Upstairs Temperature

Unit of Measurement: blank

Device Class: temperature

Scaling: .1

Humidity #

I don't have an example of the raw value so use the process of elimination. I believe it's either 0-100 or 0-.1

Name: Upstairs Humidity

Unit of Measurement: %

Device Class: humidity

Scaling: blank

Boolean #

I presume the boolean is is_fahrenheit. This has no impact so I didn't add it.

Fahrenheit #

As stated above, Temperature is always being coming in a Celsius, so I had to convert it into Fahrenheit for my own use by using a sensor template

I added this block to my main configuration, reloaded the configuration and then the upstairs_temperature_template entity exists
configuration.yaml
sensor:
 - platform: template
   sensors:
      upstairs_temperature_template:
        friendly_name: "Upstairs Temperature"
        unit_of_measurement: '°F'
        value_template: >-
          {% set t = states('sensor.upstairs_temperature') | float %}
          {{((t)*9/5)+32}}  

Main Automation #

The Trigger #

There's three potential triggers you could use:

When the outside temperature changes
When the upstairs temperature changes
On a timer

After some thought I will go with a timer. The Tuya Thermostat updates too often and the outside temperature updates every 10 minutes. Using a timer, or Time Pattern in HomeAssistant terms, is more natural to me as it's works the same as a Cron.

Trigger, Time Pattern:

Hours: *

Minutes: /10

Seconds: blank

This will run every 10 minutes

Note: Changed to a hardcoded Time trigger in the

The Conditions #

To make this more difficult on myself, joking, I have specific specifications when I want the notification:

a. Once per day b. When the upstairs temperature is above 75F c. When the outside temperature is below the upstairs temperature d. Not in the middle of the night

a. Once Per Day #

I made a toggle helper entity, inside setting > devices & services helpers, and named it Temperature Alert.

Condition, State

Entity: input_boolean.temperature_alert

Attribute: blank

State: Off

b. Upstairs is above 75F #

Condition, Numerical State

Entity: sensor.upstairs_temperature_template

Above:

Fixed Number

75

Below: blank

c. Outside is below Upstairs #
Condition, Template Condition
{{ states('sensor.upstairs_temperature_template') > states('sensor.KMOP_temperature') }}
d. Not in the Middle of the Night #

Condition, Time

After

Fixed Time

4:30pm

Before

Fixed Time

11:59pm

Note: Removed in the next post

The Actions #

Two actions need to happen:

a. My iPhone should get a notification through the HomeAssistant App b. The Temperature Alert boolean should be toggle on

a. Notification #

Action, Call a Service

Service: Notifications: Send Notification via phone_entity

Message: Open the Windows

a. Boolean #

Action, Call a Service

Service: Input Boolean: Turn On

Targets: input_boolean.temperature_alert

Raw YAML

Reset Boolean Automation #

We need to reset the Temperature Alert boolean everyday, this is easy in comparison to the main automation

The Trigger #

Trigger, Time:

Fixed Time

Time: 1:30am

The Action #

Action, Call a Service

Service: Input Boolean: Turn Off

Targets: input_boolean.temperature_alert

Raw YAML

Switch #

After swapping all my devices to a VLAN, I've had to re-add all my LocalTuya devices without help from their Discovery. Here were my steps.

Note: this pre-assumes you've done the work to get the normal Tuya integration set up. That is have a iot.tuya account and app.

Conclusion #

While the general idea works there is room for improvement; Mainly because I don't want to open my windows when the temperature is dropping to 51F, which happens a lot in Michigan. I've made this a series and will hopefully re-visit this idea.

Edit: markdownlint, textlint and meta TOML -> YAML

Window Forecast

2023-08-05T00:00:00Z

As stated in the previous post of this series, the notification is missing one thing: taking the forecast into account. This feature would be good because if the weather is dropping down to 52F during the night I do not want to be opening the windows. My current solution is to double the weather on my phone, but it would be nice to have this automated.

Problem #

The National Weather Service Integration doesn't actually have an assessable forecast entity, but the lovelace card shows it so I know the data is there.

My first step is checking the states in the Developer Tools section. This is what I see for the weather.kmop_daynight entity:

temperature: 76
temperature_unit: °F
humidity: 53
# etc..
forecast:
  - detailed_description: Partly sunny, with a high near 80. East southeast wind around 10 mph.
    datetime: '2023-08-05T12:00:00-05:00'
    daytime: true
    condition: cloudy
    precipitation_probability: 0
    wind_bearing: 112.5
    temperature: 80
    wind_speed: 10
  - detailed_description: Partly cloudy, with a low around 57. East northeast wind 5 to 10 mph.
    datetime: '2023-08-05T18:00:00-05:00'
    daytime: false
    condition: partlycloudy
    precipitation_probability: 0
    wind_bearing: 67.5
    temperature: 57
    wind_speed: 7.5
  # etc..

Playing around with the template section in the Developer Tools section I have come up with this, {{ state_attr("weather.kmop_daynight", "forecast") }}, which has the output of:

[
  {
    'detailed_description': 'Partly sunny, with a high near 80. East southeast wind around 10 mph.',
    'datetime': '2023-08-05T13:00:00-05:00',
    'daytime': True,
    'condition': 'cloudy',
    'precipitation_probability': 0,
    'wind_bearing': 112.5,
    'temperature': 80,
    'wind_speed': 10.0
  },
  {
    'detailed_description': 'Partly cloudy, with a low around 57. East northeast wind 5 to 10 mph.',
    'datetime': '2023-08-05T18:00:00-05:00',
    'daytime': False,
    'condition': 'partlycloudy',
    'precipitation_probability': 0,
    'wind_bearing': 67.5,
    'temperature': 57,
    'wind_speed': 7.5
  },
  # etc
]

From what I can see with this output is that

daynight is to determine if it's a Night forecast
The future items are at 6AM and 6PM
The first item seems to be closer to the current time's forecast and not 6AM/PM

The Entity #

Note: See the edited and final version at the bottom of this post

My first idea is this {{ state_attr("weather.kmop_daynight", "forecast").1.temperature }}, Which would be the simplest way of accomplishing what I want.

configuration.yaml

sensor:
 - platform: template
   sensors:
      forecast_temperature_template:
        friendly_name: "Next Temperature Forecast"
        unit_of_measurement: '°F'
        value_template: >- 
          {{ state_attr("weather.kmop_daynight", "forecast").1.temperature }}

A quick reload later and the entity exists!

Main Automation Change #

I've added a new condition for the Main Automation created in the previous post

Condition, Numerical State

Entity: sensor.forecast_temperature_template
Above:
- Fixed Number
- 62
Below: blank

Updated Raw YAML in Another Main Automation Change

The Updated Entity #

When the clock hits 6PM the next forecast element is the next day's 6AM, This will not work because the next day's 6AM isn't the expected temperature at 6AM, but the high for that day.

This is the updated version that picks the different forecasts depending on the day; 18 being 6PM in 24-hour time

configuration.yaml

sensor:
 - platform: template
   sensors:
      forecast_temperature_template:
        friendly_name: "Next Temperature Forecast"
        unit_of_measurement: '°F'
        value_template: >- 
          {% if now().hour >= 18 -%}
            {{ state_attr("weather.kmop_daynight", "forecast").0.temperature }}
          {%- else -%}
            {{ state_attr("weather.kmop_daynight", "forecast").1.temperature }}
          {%- endif %}

Another Main Automation Change #

After real world use, and weirdly cold nights in Michigan, I've noticed the behavior that the National Weather Service isn't reliably updating the forecast at 6pm. Instead of adding more complexity to the forecast_temperature_template entity, I will skip the 6PM check.

To do this I will replace the Time Pattern trigger with hardcoded times and the Time trigger, This will also remove the 4:30pm-11:59pm time condition. I was avoiding this because it would be a lot of fields to enter, but I'm going to write it in YAML

Trigger: Time

click 3 dots + Edit in YAML
Paste contents of code block

platform: time
at:
  - "16:30:00"
  - "16:40:00"
  - "16:50:00"
  - "17:00:00"
  - "17:10:00"
  - "17:20:00"
  - "17:30:00"
  - "17:40:00"
  - "17:50:00"
  - "18:10:00"
  - "18:20:00"
  - "18:30:00"
  - "18:40:00"
  - "18:50:00"
  - "19:00:00"
  - "19:10:00"
  - "19:20:00"
  - "19:30:00"
  - "19:40:00"
  - "19:50:00"
  - "20:00:00"
  - "20:10:00"
  - "20:20:00"
  - "20:30:00"
  - "20:40:00"
  - "20:50:00"
  - "21:00:00"
  - "21:10:00"
  - "21:20:00"
  - "21:30:00"
  - "21:40:00"
  - "21:50:00"
  - "22:00:00"
  - "22:10:00"
  - "22:20:00"
  - "22:30:00"
  - "22:40:00"
  - "22:50:00"
  - "23:00:00"
  - "23:10:00"
  - "23:20:00"
  - "23:30:00"
  - "23:40:00"
  - "23:50:00"

Updated Raw YAML

Edit: markdownlint, textlint and meta TOML -> YAML

FreePBX Announcement

2023-08-14T00:00:00Z

This will be a general outline of how to setup a Digital Acoustics Intercom and Paging device as an stand-alone Sip extension. This may not work in all FreePBX configurations, but this is how I got to work in it's most basic form; This should will work for all IP7 devices.

Hardware #

This are the parts I was given for this project

Intercom: Digital Acoustics IP7-SS20
Speaker: Nippon Tc55 100w Power Horn
1 3.81mm centers 2 pin DIN connector
- For connecting speaker to intercom
USB-A to USB-B Connector
- For connecting intercom to PC for Flashing

My intercom came with the power adapter.

Intercom Software Update #

My hardware's software was out of date, ~v5.3.3.4, and eSip doesn't seem to be an option until v6.3.4.23 on the SS20.

Most of Digital Acoustics' documentation tries to push you into using the [TalkMaster Suite](https://www.digitalacoustics.com/talkmaster-focus-software-downlo ad/) of tools. I personally had no luck updating using Firmware Management Console, which is supposed to update the firmware over a network connection. Instead I downloaded the Stand Alone Firmware installer (SAFMA) found in section 7 of the troubleshooting page ([Direct Download](https://www.digitalacoustics.com/wp-content/uploads/software/S AFMA.exe))

The firmware files can be found ip7-firmware-download, it's packaged into an exe

Important: must be updated to v5.3.5.4 first.

The manual for SAFMA is located ip7-firmware-download, generally it's self explanatory:

Open software
Select Firmware
Plugin Device using USB-A to USB-B Connector
Select COM port (may auto do it)
Reset device with Reset button
Remove and Replace USB-B Connector from device
Click Start

I found step 6 wouldn't re-register the device and would prompt to restart again, which would fail. Doing a factory reset and trying again fixed this issue, but you would have to restart this process.

Factory Reset:

Unplug device from power
Hold Volume up and down
Reattach to power
Wait until beep (it will be at full volume)

This took me 6-7 factory resets to update it. I'm not sure what the problem was.

FreePBX #

The main point of doing the extension setup next is that the extension user password is required during the intercom configuration. Again: this worked in my particular case, this was the first time I used this particular software and results may vary.

Extension can be found in the Application section in the header. Once there click New Extension and Chan_Sip, Here are the **settings I used:

General
- Name: Intercom
- Extension #
Voicemail:
- No change, all disabled
Advanced
- can reinvite: update
- host: {Static IP}
- Default user: {extension #}
- NAT Mode: No

Now Save, but don't apply config:

Go back to General
Scroll to User Section
Click Linked to user {ext#} (page link)
Change user password and take note of it

Now Apply Config

Intercom Setup #

Instead of using the [TalkMaster Suite](https://www.digitalacoustics.com/talkmaster-focus-software-downlo ad/) Admin Console, I used the eSIP Configuration Utility instead. You might be able to do it through TalkMaster, but these instruction will be in the context of eSip Utility.

Note: If you installed TalkMaster and you want to configure using eSip, the TalkMaster service must be stopped as they both use port 3000. This is how you can do that:

Open CMD (as Admin)
Run: netstat -ano | findstr :3000 (pid will be last column)
Run: talkkill /PID {enter_pid} /F

eSip Configuration #

I was unable to find the eSIP Configuration manual, but eSIP Standalone Configuration is the Admin Console's

The first step is setting the Static IP. I presume this can be done through the Utility, but I prefer reservations. I took note of the device's IP in the discovery, went to my DHCP server, found that IP, made a reservation with that MAC and reset the device.

Using the Utility, there are the settings I put in:

General
- Standalone Sip
Sip
- peer-to-peer
- SIP + RTP (checked)
- extension + auth is extension #
- pass is extension user password
Advanced
- Activate on PPT

Note: The manuals show using SIP Extension Only, but I was unable to get this to work as the device would always appear as unreachable. The way I found success was using peer-to-peer

FreePBX Validating #

Here are where the Sip logs can be found:

Reports in the header
Astrisk Info in the dropdown
Chan_sip Info on the list to the right

Scrolling down to Chan_Sip Peers you should see the new extension and the furthest column on the right should say OK ({x} ms). Generally looking at this page is faster than dialing the extension on the phone.

Fin #

When calling the extension the IP7-SS20 automatically picks up and plays the caller's voice through the speakers.

More work needs to be done this for it to be set up properly; Possibly a passcode or blocking specific phones from calling it, but neither are concerns in this setup right now.

Edit: markdownlint, textlint and meta TOML -> YAML

Omada, New Switch

2023-12-27T00:00:00Z

I received a new switch, that is compatible with Omada Controllers. This is how I made it my 'Main Switch' and swapped out the old non-compatible switch

Hardware #

My Omada Controller is running in a Virtual Machine on my Server

Existing Setup #

Omada #

Inside of Settings > Wireless Networks > WLAN, I have two entries:

Loading..., VLAN 1 (Default)
IoT, VLAN 10

Inside of Settings > Wired Networks > LAN, I had one entry:

LAN, interface, VLAN 1
IoT, interface, VLAN 10

Switch #

I have both APs connected to Port 1 & 2 on the TL-SG108PE, Port 8 going to PfSense and other misc Ethernet connections on some other Ports. I have attempted to get VLANs working with Omada & PfSense in the past, so the 802.1Q VLAN settings look like:

VLAN ID	VLAN NAME	Member Ports	Tagged Ports	Untagged Ports
1	Default	1-8	1-2, 8	3-7
10	IoT	1-2, 8	1-2, 8

Warning: These settings were a working checkpoint: Default worked. Something was wrong with IoT, It might have been PfSense settings I'm not sure. I thought I'd mention that in case somebody decides to use that.

Initial Attempt #

My first attempt was to plug and play, a 1-to-1 replacement. This did not work as the controller would not accept the Access Points and one of two issues would happen:

The Access Point would say "Disconnected"
The Access Point would get stuck in the "Adopting"

Either way, I found that the Access Points could not be pinged while attached to the new switch. Being dinner time, my temporary fix was to plug in my APs to the old switch and plug the old switch into the new switch.

Trail an Error #

I narrowed down the problem to the VLANs, but I was unable to revert everything back to a non-VLAN setup from before my previous attempt. Through Googling, I found a tidbit that mentioned that Omada doesn't handle untagged traffic well. That person was suggesting moving everything to a VLAN so that all traffic was being tagged, but that's a radical change for my network and would screw up my Home Assistant.

Port Profiles #

Port profiles are the root of the problem. Unlike my previous switch that let me explicitly tag ports with VLANs, the Omada software doesn't allow that to happen with the new switch. Instead there is a Native Network (untagged) and then Tagged Networks (tagged). There must always be a Native Network and the Native Network cannot also be put into the Tagged Networks.

Dummy VLAN (Solution) #

To get around this I made a dummy VLAN that can be used as a Native Network, which would allow me to tag all my actual traffic.

Creating #

Settings > Wired Networks > LAN: Create New LAN
Name: AP
Purpose: VLAN
VLAN: 4090
Save

Profile #

Settings > Wired Networks > LAN >| Profile: Create New Port Profile
Name: Access Point Port
Native Network: AP
Tagged Networks: LAN, IoT
Save

Setting Profile #

Devices >| SG2008P >| Ports
Click the Edit Icon in the Action column for the correct port
Profile: Access Point Port
Apply

After being applied the Access Points snapped on!

Conclusion #

This was way more fiddly than it should be. I 100% understand that untagged traffic should automatically go to the Default LAN, but that wasn't happening. I may have did something wrong in my previous attempt, I have no idea. But!- through my trails and errors my WLANs and VLANs are now working, so now I can start separating my IoT devices!

Edit: markdownlint, textlint and meta TOML -> YAML

Rest Framework (Custom User + TokenAuthentication)

2024-01-26T00:00:00Z

I've overrode Django's default user model to use email instead. When I tried to use this with Django-Rest-Framework's TokenAuthentication it did not work. This is how I overrode that as well

Serializer #

myapp/serializers.py

from django.contrib.auth import authenticate
from django.utils.translation import gettext_lazy as _

from rest_framework import serializers

class EmailAuthTokenSerializer(serializers.Serializer):
    email = serializers.CharField(
        label=_("email"),
        write_only=True
    )
    password = serializers.CharField(
        label=_("Password"),
        style={'input_type': 'password'},
        trim_whitespace=False,
        write_only=True
    )
    token = serializers.CharField(
        label=_("Token"),
        read_only=True
    )

    def validate(self, attrs):
        email = attrs.get('email')
        password = attrs.get('password')

        if email and password:
            user = authenticate(request=self.context.get('request'),
                                email=email, password=password)

            # The authenticate call simply returns None for is_active=False
            # users. (Assuming the default ModelBackend authentication
            # backend.)
            if not user:
                msg = _('Unable to log in with provided credentials.')
                raise serializers.ValidationError(msg, code='authorization')
        else:
            msg = _('Must include "email" and "password".')
            raise serializers.ValidationError(msg, code='authorization')

        attrs['user'] = user
        return attrs

View #

myapp/view.py

from rest_framework.authtoken.views import ObtainAuthToken

from .serializers import EmailAuthTokenSerializer

class EmailObtainAuthToken(ObtainAuthToken):
    serializer_class = EmailAuthTokenSerializer

obtain_auth_token = EmailObtainAuthToken.as_view()

URLs #

myapp/urls.py

from django.urls import path

from . import views

urlpatterns = [
    # ...
    path('api-token-auth/', views.obtain_auth_token),
]

Pretty basic but thought I should jot it down as my initial google search wasn't fruitful. I didn't spend too much time looking

Edit: markdownlint, textlint and meta TOML -> YAML

HA Forecast v2

2025-07-13T00:00:00Z

I have been lackadaisical with my Home Assistant updates, but when I updated it late December of 2024 I've broken all my forecast automations. I had for a short while swapped to openweathermap, but now that even seems to be broken. With summer heat at an all time peak I would like to get this working again. I've moderate research on this... and it's a nightmare. As of writing my instance is 2025.6.2

Problem #

{{ state_attr("weather.kmop_daynight", "forecast") }} has now been deprecated and now you have to manually call to get the forecast. From the 3-4 threads I have read, this requires a template, with a trigger and an action. The major problem right off the bat was testing anything. The forums described "Developer Tools" and the "Services" tab, I don't have any of that.

Testing #

After plenty of failures, "Services" has now been renamed to "Actions". Going there a simple test is:

Select weather.get_forecasts in the search
Select the KMOP entity
Forecast Type: Twice Daily

This is the YAML for the call

action: weather.get_forecasts
data:
  type: twice_daily
target:
  entity_id: weather.kmop_daynight
response_variable: response

Clicking to preform action outputs it in this format

weather.kmop_daynight:
  forecast:
    - datetime: ""
      precipitation_probability: 0
      is_daytime: false
    - datetime: ""
      # etc

Scrolling down you can click the COPY TO CLIPBOARD (TEMPLATE) button and this data can then be used inside the Template tab. This is also where you see that the response_variable is in fact being set to response

Automating #

This is where the template part comes in. I created a new file templates.yaml and added this line template: !include templates.yaml in my main configuration

I've found this file was specific on action and sensor not having a dash

templates.yaml,

- trigger:
  - platform: time_pattern
    minutes: "/15"
  action:
    - service: weather.get_forecasts
      data:
        type: twice_daily
      target:
        entity_id: weather.kmop_daynight
      response_variable: response
  sensor:
    - name: Weather Forecast
      unique_id: weather_forecast
      state: "{{ now() }}"
      attributes:
        forecast: "{{ response['weather.kmop_daynight'].forecast }}"

After creating this and resetting Home Assistant this new sensor appeared as unknown. I am hoping that it will configure after 15 minutes. Which happened!

Converting #

Now to update the entity created in the previous post

configuration.yaml

sensor:
 - platform: template
   sensors:
      forecast_temperature_template:
        friendly_name: "Next Temperature Forecast"
        unit_of_measurement: '°F'
        value_template: >- 
          {% if states("sensor.weather_forecast") != "unavailable" %}
            {% if now().hour >= 18 -%}
              {{ state_attr("sensor.weather_forecast", "forecast").0.temperature }}
            {%- else -%}
              {{ state_attr("sensor.weather_forecast", "forecast").1.temperature }}
            {%- endif %}
          {% else %}
            unavailable
          {% endif %}

I had added an "unavailable" if to all my templates to avoid error logs

Next #

My current plans is to keep this running for a week or two to check that it's working and then changed the trigger to a time platform. This would lower the amount of requests.

InsightHome Modbus RTU

2025-10-07T00:00:00Z

I've been playing with an InsightHome Inverter Hub from Schinder Electric. It has a Modbus RTU interface which I have connected with using an RS485 to USB dongle, the results have always been timeouts. My assumption is that the device is actually the Master/Client of the Modbus system and is not compatible as a Slave/Server.

Going another route, I've created a Modbus Slave/Server using the 502 (SunSpec) standard. I validated all the registers with the pysunspec2 package. During the device detection my device is found, there are no errors, but there is no further registration process and my device doesn't appear. Checking the Network Log, the hub replies that the device "Type" as "unknown" and a "isDead" attribute is "N/a"

Here are commands the Hub runs during the Discovery process, in order:

Command	Addr	Size	Schema
READ_HOLD	1	1	503
READ_HOLD	1	10	503
READ_HOLD	40020	16	502
READ_HOLD	11	1	503
READ_HOLD	40020	16	502
READ_HOLD	40020	16	502
READ_INPUT	4999	1	?
READ_INPUT	4999	1	?
READ_INPUT	4999	1	?
READ_HOLD	40020	16	502
READ_HOLD	49	10	?
READ_HOLD	49	10	?
READ_HOLD	49	10	?
READ_HOLD	49	10	?
READ_HOLD	3085	1	?
READ_HOLD	32001	1	?
READ_HOLD	1014	1	?
READ_INPUT	42	3	?
READ_INPUT	1	10	503
READ_INPUT	1	10	503

Looking at the known mappings, it's checking for Device/Model names and, I presume, checking it against an internal list of supported devices. Which.. is a shame!

Note: As a debugging process I cross referenced all these requests with my Schinder devices to make sure my Slave/Server is responding the same to each.

This entire process has been nonsensical. I wanted to share as I haven't found a similar attempt online. I'd recommend to stick to Modbus TCP, if you are working with these.

NOTE(neal@2026-08-09): I have had more experiences with solar inverters in the past year and this was the real "issue" I ran into with Schinder's Inverters. They did a wonderful job with this product and I enjoyed working with them. These inverters do not seem to be as popular as they once were, due to being undersized for today's market and built as a modular system. I hope they release a higher kW "all-in-one" version with similar software capabilities.

Blog Refactor

2026-08-09T00:00:00Z

This blog was originally made using Hugo, I had made the theme myself and it looked ugly. This year at my work we moved away from WordPress to a static site. When it came to porting the news section (mainly for less broken links) we tried Eleventy. This was mainly due to this cool idea of mashing template languages in a flexible way, which would be good idea with potential future editors. I liked it!

I decided to refactor this website to use Eleventy too. I've removed features such as comments and some posts that were not that good. I also did a major cosmetic overhaul, via Claude, to more match my terminal aesthetic I was going for. This is the colorscheme I use everywhere; desktop, terminal, editor. This shift is still a work in progress.

In lieu of comments, please contact me directly via my email: neal@joslin.io