Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved
Collapse
Discussion Forum to share and further the development of home control and automation, independent of platforms.
M

mgvra

@mgvra
openLuup console disappeared - 500 - Internal Server Error
A
Love openLuup - it just keeps working perfectly. I started looking at trying to add a gen4 Shelly device to the Shelly plugin via L_ShellyBridge.lua. The plugin is a little uncooked (no rudeness intended), so a bit of a rabbit hole for me. All of a sudden no console pages available in either Firefox or Chrome. AltUI works perfectly and all the log files indicate no errors. openLuup still running everything works as it should - just no console pages. I possibly screwed something up but any recently changes files show no problems. The original/ backup of L_ShellyBridge.lua was reinstated but still no console. Bit stumped on this one. Not sure how to debug. Any ideas?
Plugins
Logon screen timeout
G
Noticing since 170 that the lock screen doesn't switch to the logon prompt but, rather, stays on the active UI until such time as you go to click something within it. Then it jumps to the login screen. Brave browser Brave 1.92.139 (Official Build) (arm64) Chromium: 150.0.7871.114
Multi-System Reactor
Reactor (Multi-System/Multi-Hub) Announcements
toggledbitsT
Build 21228 has been released. Docker images available from DockerHub as usual, and bare-metal packages here. Home Assistant up to version 2021.8.6 supported; the online version of the manual will now state the current supported versions; Fix an error in OWMWeatherController that could cause it to stop updating; Unify the approach to entity filtering on all hub interface classes (controllers); this works for device entities only; it may be extended to other entities later; Improve error detail in messages for EzloController during auth phase; Add isRuleSet() and isRuleEnabled() functions to expressions extensions; Implement set action for lock and passage capabilities (makes them more easily scriptable in some cases); Fix a place in the UI where 24-hour time was not being displayed.
Multi-System Reactor
[MSR] Copy&past of actions and/or drag&drop between set/reset
therealdbT
Hey @toggledbits One thing that bothers me while doing work on new systems/new features, is that I cannot copy&paste actions, and I cannot drag&drop between set and resets. #1 is for when I want to copy an action between different rules opened in two separate browser windows, while #2 is when I just need to flip a bunch of actions in the reset, or move some logic back and forth. Both will be appreciated, but I understand the technical challenges. Thanks!
Multi-System Reactor
Upgrade advice - upgrade from aarch64 to ARM64 image
T
I'm currently on version 26011. I understand that the aarch64 image is no longer supported. So, I therefore need to update to the ARM64 image. Can anyone possibly suggest how I update my docker compose.yaml file (see below). Ideally I'd like to keep my existing reactions etc. rather than start from scratch. # Multi-System Reactor template docker-compose.yml (version 22160) # # Change the lines indicated by "DO"... # services: reactor: container_name: reactor environment: # DO change the TZ: line to set your local time zone. # See valid TZ list: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones TZ: GB # # DO NOT change this path. Your directory location is in "source" below. REACTOR_DATA_PREFIX: /var/reactor # DO change the image below to the one you are using (e.g. armv7l or aarch64 for RPi 4) image: toggledbits/reactor:latest-aarch64 restart: "always" expose: - 8111 ports: - 8111:8111 volumes: # DO change the /home/username/reactor below to the directory you created for # your local data; DO NOT change the /var/reactor part - /home/pi/docker/reactor:/var/reactor - /etc/localtime:/etc/localtime:ro tmpfs: /tmp
Multi-System Reactor
Alexa for MSR, any interest?
MikeReadingtonM
Topic thumbnail image
Multi-System Reactor
Ezlo Paid Subscription for Vera Cloud Services
toggledbitsT
It appears that Ezlo is going to new levels of paid subscription for cloud services supporting Vera hubs. I have to congratulate them. It will soon be 8 years since Ezlo acquired Vera, and despite their purported financial and "intellectual" capital, they have to date not produced a viable full replacement for Vera. Now they are going to charge extra for services for a platform that they stopped updating years ago. If you know anyone who hasn't yet fully moved on from Captain Ahab's White Whale Chase, please remind them that my Decouple project is still up on Github to decouple a Vera Plus/Secure/Edge from Vera/Ezlo's cloud services. Veras have been said to misbehave when they can't reach the mother ship. I have also written my first new Vera plugin in... six years? more?... the AlertPushover project will send Vera hub alerts to Pushover, so you can still get messages generated by your Vera hub without paying for Ezlo's cloud service. It's crude but functional (i.e. better than nothing/worth every penny paid). These two projects won't replace the functionality of their cloud service and app for those who need those things. But any that don't, this may help bridge the gap. Hopefully these stragglers who have waited so long and been disappointed so often will get the idea that it's time to move on.
General Discussion
[RESOLVED] Telegram notification broke with latest update
3
Topic thumbnail image
Multi-System Reactor
[RESOLVED] Phantom device, “INFO” appears
wmarcolinW
Topic thumbnail image
Multi-System Reactor
[RESOLVED] Mode Status NULL
wmarcolinW
Topic thumbnail image
Multi-System Reactor
[RESOLVED] HTTP query failing after version 26177
wmarcolinW
Topic thumbnail image
Multi-System Reactor
Question about the find function
wmarcolinW
Topic thumbnail image
Multi-System Reactor
[Answered] OK to remove old json files?
3
Topic thumbnail image
Multi-System Reactor
Deprecation Announcement: 32-bit ARM *docker* images
toggledbitsT
If you are using the armv7l docker image, the OpenJS Foundation that publishes node is no longer producing 32-bit builds as of v24. That means the last supported LTS version of node for armv7l is v22, which will go End-of-Life in May 2027. Therefore, the Reactor armv7l image is now deprecated and will only be produced until node v22 goes EOL, and I will not publish armv7l images beyond that date. If you are running an RPi 3 or earlier with Reactor, you are on this image, and will need to upgrade hardware to a 64-bit model and use the arm64 image. If you need help getting it done, ask in this category.
Multi-System Reactor
[Solved] build 26150 - engine not starting
G
@toggledbits I pulled the image (well, Watchtower did) and within minutes the whole system went offline. The log looks like it ends with 26143. [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-mkahsmgf/26qq82mw-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lqyfljfi/22f8on0t-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lsb61rw8/24oenqi2-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/rule-lrh58he0:S-1c00gfib-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/1c00dylr-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lrh58he0/1nam9w5u-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-miuh2qqi/22ls4lql-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-kwc6rmci/rule-kwc6rmci:S-1vj8sdfc-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-kwc6rmci/rule-kwc6rmci:S-1qanz01x-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/24lq19p6-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-mk0o8iox/23oy468y-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-miscg2h3/rule-miscg2h3:S-22gmbq1c-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-kxgrfjke/238p0old-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-m7ccsso5/re-m7ccsso5-1r0myjxa-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/19nl9wq2-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/rule-ladyja6a:S-yl3xk9t-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ladyja6a/rule-ladyja6a:S-yl3vv5m-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-ln7j2nqp/re-ln7j2nqp-22mx9lzd-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-ln7j2nqp/22mx87c8-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-licneppy/1mzwe7ht-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-ml3194ih/25jqt1j4-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-kxgrg7kf/227hshak-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-reactorexmachina/13ua1p95-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-reactorexmachina/13uagam7-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-grpvl9oypg/rule-grpvl9oypg:R-134x4cbv-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-grpvl9oypg/rule-grpvl9oypg:R-134x2fyl-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#re-lscjrws1/238p5c22-cons [latest-26143]2026-05-31T15:23:44.547Z <default:INFO> Closing container Container#Predicate#rule-lbwr0jvq/1xkczf03-cons [latest-26143]2026-05-31T15:23:44.547Z <Structure:NOTICE> Structure Structure#1 stopped [latest-26143]2026-05-31T15:23:44.547Z <app:NOTICE> Closing APIs... [latest-26143]2026-05-31T15:23:44.547Z <wsapi:NOTICE> wsapi: closing... [latest-26143]2026-05-31T15:23:44.547Z <wsapi:NOTICE> wsapi: disconnecting from "192.168.1.23#82" (1001 service closing) [latest-26143]2026-05-31T15:23:44.548Z <httpapi:NOTICE> HTTP API closing... [latest-26143]2026-05-31T15:23:44.549Z <wsapi:NOTICE> wsapi: server closed [latest-26143]2026-05-31T15:23:44.549Z <httpapi:INFO> HTTP server closed. [latest-26143]2026-05-31T15:23:44.549Z <app:NOTICE> Stopping timers... [latest-26143]2026-05-31T15:23:44.551Z <app:null> Shutdown complete, process ID 1 [latest-26143]2026-05-31T15:23:44.551Z <app:null> Closing logs... [latest-26143]2026-05-31T15:23:44.551Z <default:null> Closing log I can SSH to the VM. Alas, I do not have the previous image for 26143 as I'm a little too quick sometimes on housekeeping.
Multi-System Reactor
Farewell, oh good and faithful servant!
CatmanV2C
Today marks another milestone in my Home Automation journey. After tripping the main breaker once, and shedding more blood than is normally recommended, the underfloor heating (which was the last Z-wave device on my system) has been replaced with a Zigbee one. Edited reactor.conf Disabled z-way-server Disabled Openluup Z-wave is no more.... C
General Discussion
http request action & digest auth
tunnusT
I’m using the HTTP Request action in MSR and need to authenticate against an endpoint that uses HTTP Digest authentication. Now that endpoint was changed to use SHA-256 in digest auth, so I would like to know if MSR supports it, or is it limited to MD5-based digest auth?
Multi-System Reactor
Cloning actions in reactions does not work
tunnusT
With build 26140 (on Docker) I'm not able to clone any actions in reactions. Using Chrome if it has any relevance.
Multi-System Reactor
Has ping command been removed?
tunnusT
Topic thumbnail image
Multi-System Reactor
ReferenceError with Home Assistant data & build 26140
tunnusT
Topic thumbnail image
Multi-System Reactor
About
Posts
29
Topics
10
Shares
0
Groups
0
Followers
0
Following
0

Posts

Recent Best Controversial

  • Dynamic MQTT topics and parameters
    M mgvra

    Hi,
    I've installed the latest version 26059 and can confirm that the parameter substitution works perfectly!
    Thanks a lot for the quick fix and the feature update @toggledbits

    Here's my setup

    local_mqtt_capabilities.yaml

    x_mqtt_annunciator_panel:
        actions:
          on:
            arguments:
              led:
                type: int
                min: 1
                max: 45
              color:
                type: string
              effect:
                type: string
                default: "static"
                values:
                 - static
                 - blink
                 - breath
              speed:
                type: int
                default: 500
          off:
            arguments:
              led:
                type: int
                min: 1
                max: 45
          static:
            arguments:
              led:
                type: int
                min: 1
                max: 45
              color:
                type: string
          blink:
            arguments:
              led:
                type: int
                min: 1
                max: 45
              color:
                type: string
              speed:
                type: int
                default: 500
          breath:
            arguments:
              led:
                type: int
                min: 1
                max: 45
              color:
                type: string
              speed:
                type: int
                default: 500
          brightness:
            arguments:
              value:
                type: int
                min: 0
                max: 255
    

    local_mqtt_devices.yaml

      annunciator-panel:
        capabilities:
         - x_mqtt_annunciator_panel
        requires: [panel]
        actions:
          x_mqtt_annunciator_panel:
            on:
              topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
              retain: true
              payload:
                expr: >
                  { "color": parameters.color, "effect": parameters.effect, "speed": parameters.speed }
                type: json
            off:
              topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
              retain: true
              payload:
                expr: >
                  { "color": "off", "effect": "static" }
                type: json
            static:
              topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
              retain: true
              payload:
                expr: >
                  { "color": parameters.color, "effect": "static" }
                type: json
            blink:
              topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
              retain: true
              payload:
                expr: >
                  { "color": parameters.color, "effect": "blink", "speed": parameters.speed }
                type: json
            breath:
              topic: "annunciator/panel/%panel%/led/%parameters.led%/set"
              retain: true
              payload:
                expr: >
                  { "color": parameters.color, "effect": "breath", "speed": parameters.speed }
                type: json
            brightness:
              topic: "annunciator/panel/brightness"
              retain: true
              payload:
                expr: >
                  { "value": parameters.value }
                type: json
    

    reactor.yaml

          # Annunciator panels
            annunciator-panel-1:
              name: 'Annunciator panel 1'
              panel: 1
              include: annunciator-panel
    
            annunciator-panel-2:
              name: 'Annunciator panel 2'
              panel: 2
              include: annunciator-panel
    

    Note that the brightness control is not panel-dependent, as it uses the rpi-ws281x-native library's global brightness attribute. This works well for my setup, as I want all panels to share the same brightness level anyway. Speaking of brightness, it will be controlled by the technical room's PIR and MSR rules that dim or turn off the panels when nobody is present.

    Below is the setup for the ventilation unit (AHU) indicator light:

    • Green: Running OK
    • Yellow: Switched off
    • Blinking Red: Error

    ba29ea20-cc5f-4998-abd7-c14456600fce-Screenshot from 2026-03-02 18-25-07.png

    And here are the panel operations:

    b8995409-8929-4c71-bba4-5ac7f8eae3f4-Screenshot from 2026-03-02 18-23-40.png

    br,
    mgvra

    Multi-System Reactor

  • MQTTController configuration with multiple topics per entity
    M mgvra

    Hi,
    This post is a kind of feature request and a question at the same time.
    I've just recently started to play with the MSR, thanks to friend of mine @tunnus
    who recommended to try it out. So bear with me if I'm asking trivial or stupid questions.

    Some background information of my setup

    I have a KNX bus as a hardware backbone which I'm accessing through my own KNXNet/IP protocol stack implementation. On top of that I have NodeJS based dockerized microservices which are communicating using the MQTT. Since I'm still lacking a good rule engine, I've decided to try the MSR, and so far everything is looking pretty promising.

    MSR version: latest-22274-24dfd72c (tested on Ubuntu but will eventually run on RPi 4)
    MQTTController version: 22260

    So what is the problem then?

    Having well over 100 entities (62 relays alone) definitely means that I have to go with the entity template configuration. I've already succesfully POCed some simple binary and value sensors, e.g. entities that provide only state changes and are so to speak read-only. These are working just fine, but the problem lies within the switches and generally speaking
    entities that have actions.

    Screenshot from 2022-10-08 13-11-28.png

    But let me first explain how I do the MQTT topic mapping for the KNX group addresses, which are basically unique identifiers for the attributes and functions of the KNX devices.

    For example a motion sensor has a single group address, let's say 0/6/0,
    for which we the following MQTT topics:

    For status updates: /knx/0-6-0/status
    And for the read operation: /knx/0-6-0/read

    The group address 0/6/0 is formatted as 0-6-0 since it would clash with the MQTT topic.

    motion-sensors.png knx-devices-ok.png

    The problem arises with swiches and gets even worse with dimmable lights.

    In the KNX world we have separate group addresses for the statuses and for the write operations.

    For example a simple switch would have a setup like this:

    0/0/55 write (toggle on/off)
    0/0/56 status (current status, can be also used to read the status)

    And for the dimmable light we may have:

    0/0/3 write (toggle on/off)
    0/0/4 write (absolute dimming value)
    0/0/5 write (relative dimming value)
    0/0/6 status (current status, can be also used to read the status)

    Now these would map to MQTT topics like this:

    knx/0-0-55/write
    knx/0-0-56/read
    knx/0-0-56/status

    knx/0-0-3/write
    knx/0-0-4/write
    knx/0-0-5/write
    knx/0-0-6/status
    knx/0-0-6/read

    And there lies the problem. Since the MQTTController configration is only interpolating the %topic% variable, it's not possible to pass those additional 'write' topics into the template.

    knx-switch-definition-problem.png

    knx-switch-nok.png

    I've tried to get my head around this and didn't find any easy solution. One that crossed mind was the possibility to interpolate all the entity's config keys into the template.

    I'm open to all suggestions since I would love get on writing the rules and logic with the MSR. Anyway, keep up the good work @toggledbits !

    br,
    mgvra

    Multi-System Reactor

  • Rule's sustain / delay reset etc. value parameterization thru entities
    M mgvra

    Some background
    I have two simple rules that will toggle my carport's down lights depending on outdoor brightness when I open the motorized sliding gate. I.e. if the brightness is 1500 lux or less and the gate is opened, the down lights will be switched on, and when the gate is closed, the lights will switch off after 3 minutes. Pretty simple 'coming home' functionality so to speak.

    Here's the switch off rule showing the 'hard coded' thresholds

    Screenshot from 2023-10-31 18-44-46.png

    The problem
    I would like to parameterize the lux and switch off delay using entities. I bet the lux threshold can be done with local expressions the same way I do my WC background music scheduling:

    weekdays_enabled = (time() >= time(getEntity( "mqtt>wc-music-weekdays-enable" ).attributes.string_sensor.value )) && (time() <= time(getEntity( "mqtt>wc-music-weekdays-disable" ).attributes.string_sensor.value ))
    

    But the since I'm using the Condition must be sustained for functionality for the switch off rule, I have no idea how to parameterize that with some entity value.

    So my question is that is it even possible to do this using entities or could there some other way to accomplish the same functionality? In this example it's the sustain -value but I might need same kind of parameterization for the delay reset also.

    I have to go with entities, since my own HA system will provide the threshold values for the MSR through the MQTTController.

    Help would be appreciated @toggledbits
    br,
    mgvra

    MSR latest-23302-b7def56a and MQTTController [0.1.23254]

    Multi-System Reactor

  • Rule's sustain / delay reset etc. value parameterization thru entities
    M mgvra

    Thanks for your quick reply!

    You can use expressions in condition operands by using the substitution syntax: ${{ your-expression }}

    I'll use that for the brightness threshold.

    The workaround is to group conditions and use additional conditions as gating criteria. For example, if you would change the "sustained for" delay based on time of day, say 120 for day and 600 for night, then you would have conditions structured like this:

    Group A - Daytime -- AND group
        Rule Condition: Rule "Is Day" is TRUE
        Entity Condition: some entity test that tests a value
            condition option: Sustained for 120 seconds
    Group B - Night -- AND group
        Rule Condition: Rule "Is Day" is FALSE
        Entity Condition: the same test as used in group A
            condition option: Sustained for 600 seconds
    

    Well unfortunately this doesn't help much if I need to set an arbitrary delay value from my custom UI.

    You cannot use expression substitution in the values of condition options. These are required to be constants (literal values).

    Could this be a new feature request to support expression substitution in timeout values (sustain / delay reset etc) if it's feasible to implement?

    br,
    mgvra

    Multi-System Reactor

  • case statement with a single when clause fails
    M mgvra

    A case with only a single when (and possibly an else) is an if statement, so why not use that? This is the workaround/recommendation. Using case in this way just seems unnecessarily complex

    Well that's true and I don't think anyone uses the case-when structure with a single when. But for example in my case, I was testing the expressions, had written only one section and was getting this mysterious syntax error. As a software engineer myself, coming from C / Java / JS background, I naturally associated the case-when structure to switch-case where it's perfectly fine to have a single case, although as you mentioned, does not make much sense.

    This is not a bug that needs to be necessarily fixed ASAP, but it would be nice if you could add a clarification to the manual, stating that the case-when structure must have at least two when sections.

    Multi-System Reactor

  • Custom capabilities in MQTT templates
    M mgvra

    Hi,
    I'm trying to integrate the sonos-mqtt (https://sonos2mqtt.svrooij.io/) with the MSR and it's coming along nicely so far.
    But cannot wrap my head around how to define custom capabilities in MQTT templates. I need this for the TTS announcements and similarly for the notification sounds where I would pass the sound file as parameter.

    So this is what I have in the local_mqtt_devices.yaml

    capabilities:
      x_sonos_announcement:
        attributes:
        actions:
          speak:
            arguments:
              text:
                type: string
              volume:
                type: int
              delay:
                type: int
    

    And this is the template:

    templates:
      sonos-announcement: 
        capabilities: 
          - x_sonos_announcement
        actions:
          x_sonos_announcement:
            speak:
              topic: "sonos/cmd/speak"
              payload:
                expr: >
                  { "text": parameters.text, "volume": parameters.volume, "delayMs": parameters.delay, "onlyWhenPlaying": false, "engine": "neural" }
                type: json
    

    So the speak action should send something like this to topic sonos/cmd/speak

    {
      "text": "message goes here",
      "volume": 50,
      "delayMs": 100,
      "onlyWhenPlaying": false,
      "engine": "neural"
    }
    

    At startup the MSR seems to be quite unhappy with my configuration:

    reactor  | [latest-25016]2025-02-09T08:19:59.029Z <MQTTController:WARN> MQTTController#mqtt entity Entity#mqtt>sonos-announcement unable to configure capabilities [Array][ "x_sonos_announcement" ]
    reactor  | i18n: missing fi-FI language string: Configuration for {0:q} is incomplete because the following requested capabilities are undefined: {1}
    reactor  | i18n: missing fi-FI language string: Configuration for {0:q} has unrecognized capability {1:q} in actions
    reactor  | Trace: Configuration for {0:q} is incomplete because the following requested capabilities are undefined: {1}
    reactor  |     at _T (/opt/reactor/server/lib/i18n.js:611:28)
    reactor  |     at AlertManager.addAlert (/opt/reactor/server/lib/AlertManager.js:125:25)
    reactor  |     at MQTTController.sendWarning (/opt/reactor/server/lib/Controller.js:627:30)
    reactor  |     at MQTTController.start (/var/reactor/ext/MQTTController/MQTTController.js:268:26)
    reactor  |     at async Promise.allSettled (index 0)
    
    Configuration for "sonos-announcement" has unrecognized capability "x_sonos_announcement" in actions
    Controller: MQTTController#mqtt
    Last 10:21:37 AM
    
    Configuration for "sonos-announcement" is incomplete because the following requested capabilities are undefined: x_sonos_announcement
    Controller: MQTTController#mqtt
    Last 10:21:37 AM
    

    This is probably a pretty stupid question and the approach may not even work at all, but maybe someone or @toggledbits for sure, could point me to the right direction.
    Basically the idea is to be able to send TTS messages from reactions using entity actions. I've previously used HTTP requests to Sonos HTTP API (https://hub.docker.com/r/chrisns/docker-node-sonos-http-api/) for the same functionality, but since moving to sonos-mqtt, I need a way to send the TTS notifications using MQTTController. Along with the actual message, volume and delay must also be parameterizable.

    br,
    mgvra

    MSR latest-25016-d47fea38 / MQTTController [0.2.24293]

    Multi-System Reactor

  • Widget deletion does not work and landing page (status) is empy
    M mgvra

    Hi,
    Well my bad and classic RTFM case. Actually I also tried to drag it to the top but it seems that you have to hit the top bar on the spot in order to trigger the deletion, which is fine when you know it. And well right after the post, new release came out which fixed the landing page problem - nice work!

    br,
    mgvra

    Multi-System Reactor

  • Requesting a proper ARM64/aarch64 Docker image (Pi 5 support)
    M mgvra

    Hi,

    I'm in the process of migrating from a Raspberry Pi 4 (ARMv7) to a Raspberry Pi 5 (ARMv8/aarch64), but I’ve run into an issue: there is no proper ARMv8/aarch64 image available.

    None of the existing images run on the Pi 5 - they all exit immediately with code 139 (segmentation fault), which typically indicates that the binaries inside the image are not compatible with the ARM64/aarch64 architecture used by the Pi 5.

    Would it be possible to publish a correct ARMv8/aarch64 (linux/arm64) image?
    Building one should be relatively straightforward using docker buildx with multi-arch support. For example, my own Node.js images are built this way:

    docker buildx build --push \
        -t <localrepo>/<project>:<tag> \
        --platform=linux/arm64,linux/amd64 \
        --file ./apps/<project>/Dockerfile .
    

    This produces both the AMD64 and ARM64/v8 variants automatically.

    Also, as a side note, it may be best to avoid using Alpine as the base image for the ARM64 build, since musl-based builds often cause compatibility issues and unnecessary headaches. A glibc-based base image (e.g., Debian or Ubuntu) tends to work far more reliably on ARM64, especially for Node.js applications.

    @toggledbits - tagging you in case you missed this.

    Thanks,
    mgvra

    Multi-System Reactor

  • Requesting a proper ARM64/aarch64 Docker image (Pi 5 support)
    M mgvra

    The latest-arm64 works perfectly now on my RPi5 - huge thanks for pushing the arm64 Bookworm build! 🙌
    This was the last showstopper for my RPi4 → RPi5 migration, so I can finally continue the move.

    Here’s the container coming up cleanly:

    mgvra@desktop:/development/knx-hal-mono$ docker --context production-rpi5 compose --env-file .env-prod up msr
    [+] Running 1/1
     ✔ Container mosquitto  Running 0.0s 
    Attaching to msr
    msr  | Reactor latest-25315-bc301993 app 25315 configuration from /var/reactor/config
    msr  | NODE_PATH /opt/reactor:/opt/reactor/node_modules
    msr  | [latest-25315]2025-11-15T03:42:09.308Z <app:null> Reactor build latest-25315-bc301993 starting on v24.11.1 /usr/local/bin/node
    msr  | [latest-25315]2025-11-15T03:42:09.309Z <app:null> Process ID 1 user/group 0/0; docker; platform linux/arm64 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16); locale (undefined)
    msr  | [latest-25315]2025-11-15T03:42:09.309Z <app:null> Basedir /opt/reactor; data in /var/reactor/storage
    msr  | [latest-25315]2025-11-15T03:42:09.309Z <app:null> NODE_PATH=/opt/reactor:/opt/reactor/node_modules
    msr  | [latest-25315]2025-11-15T03:42:09.332Z <app:null> Resolved timezone=Europe/Helsinki, environment TZ=Europe/Helsinki; offset minutes from UTC=120
    .
    .
    .
    

    Thanks again — I dropped a few drams for such a fast support. 🥃
    br,
    mgvra

    Multi-System Reactor
  • Login

  • Don't have an account? Register

  • Login or register to search.
  • First post
    Last post
0
  • Categories
  • Recent
  • Tags
  • Popular
  • Unsolved