Home Assistant json config on UI Code tab

apella12 · January 31, 2024, 1:44am

I have been testing some HA configs from Zwave-js-ui. They work fine with one exception, they are displayed on the UI code tab with errors. The impact is that changes (like removing a config) can’t be done. I had to delete the thing and rescan to pick up the changes. My guess is that the config is split-up to fit a certain field size on the UI code tab and that causes the errors.
The errors are;

all collection items must start at the same column
Nested mapping are not allowed in compact mappings
Implicit keys must be followed by map values
Implicit map keys must be on a single line

Sorry for the picture, but the point is that the HA config

was pulled directly from MQTT (this was one line).

{"payload_on":8,"payload_off":0,"value_template":"{{ value_json.value }}","device_class":"motion","state_topic":"zwave1/nodeID_66/notification/endpoint_0/Home_Security/Motion_sensor_status","availability":[{"payload_available":"true","payload_not_available":"false","topic":"zwave1/nodeID_66/status","value_template":"{{'true' if value_json.value else 'false'}}"},{"topic":"zwave1/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status","value_template":"{{'online' if value_json.value else 'offline'}}"},{"payload_available":"true","payload_not_available":"false","topic":"zwave1/driver/status"}],"availability_mode":"all","json_attributes_topic":"zwave1/nodeID_66/notification/endpoint_0/Home_Security/Motion_sensor_status","device":{"identifiers":["zwavejs2mqtt_0xf1c43721_node66"],"manufacturer":"Zooz","model":"Motion and Vibration Sensor (ZSE18)","name":"nodeID_66","sw_version":"1.3"},"name":"nodeID_66_motion_sensor_status","unique_id":"zwavejs2mqtt_0xf1c43721_66-113-0-Home_Security-Motion_sensor_status"}

Can anything be done or are there UI constraints?

JustinG · January 31, 2024, 2:40am

Those aren’t UI specific errors, those are just yaml parsing errors. A lot of that comes from the : in the json string. You need to use a format that explicitly defines that whole thing as a string instead of potentially more yaml (which is what it is currently trying to parse it as).

If it were smaller I would just say enclose the whole thing in an outer layer of single quotes, but for something this long, to improve readability, I would suggest using one of the yaml block identifiers, | or >. For example:

config: >
  {"payload_on":8,"payload_off":0,"value_template":"{{ value_json.value }}","device_class":"motion","state_topic":"zwave1/nodeID_66/notification/endpoint_0/Home_Security/Motion_sensor_status","availability":[{"payload_available":"true","payload_not_available":"false","topic":"zwave1/nodeID_66/status","value_template":"{{'true' if value_json.value else 'false'}}"},{"topic":"zwave1/_CLIENTS/ZWAVE_GATEWAY-zwave-js-ui/status","value_template":"{{'online' if value_json.value else 'offline'}}"},{"payload_available":"true","payload_not_available":"false","topic":"zwave1/driver/status"}],"availability_mode":"all","json_attributes_topic":"zwave1/nodeID_66/notification/endpoint_0/Home_Security/Motion_sensor_status","device":{"identifiers":["zwavejs2mqtt_0xf1c43721_node66"],"manufacturer":"Zooz","model":"Motion and Vibration Sensor (ZSE18)","name":"nodeID_66","sw_version":"1.3"},"name":"nodeID_66_motion_sensor_status","unique_id":"zwavejs2mqtt_0xf1c43721_66-113-0-Home_Security-Motion_sensor_status"}

apella12 · January 31, 2024, 2:59am

That makes sense, except I’m getting channel config from another program (via Mqtt) and it is “grayed out” in OH. No easy way to modify it AFAIK

JustinG · January 31, 2024, 3:43am

Ah, I see. Then that sounds like an issue with how the MQTT binding is processing that incoming data, and any fix probably has to happen at that step. In addition, it should probably convert that big json string to yaml anyway for best compatibility with OH configuration.

rlkoshak · January 31, 2024, 4:10pm

Because this Thing is auto discovered, I wonder if anyone has even considered the possibility that someone might want to manually change it from the code tab.

The system truth is the JSON returned by the REST API/stored in the JSONDB. As best as I can tell, that original JSON appears to be valid.

IIRC, the YAML is actually generated by MainUI in the browser. If not it’s created in core. I would not be surprised if there are come cases (perhaps many cases) where the conversion between JSON and YAML and back hits edge cases it cannot handle.

I do know for UI rules, for example, the code gets modified between the YAML and the JSON as YAML can support newlines but JSON cannot.

For example this YAML:

configuration: {}
triggers:
  - id: "1"
    configuration:
      itemName: AdGuard_Protection
      state: ON
      previousState: OFF
    type: core.ItemStateChangeTrigger
  - id: "2"
    configuration:
      itemName: AdGuard_Protection
      state: OFF
      previousState: ON
    type: core.ItemStateChangeTrigger
conditions: []
actions:
  - inputs: {}
    id: "3"
    label: Send Alert
    description: Uses the alerting library to send an alert level message
    configuration:
      type: application/javascript
      script: >
        var {alerting} = require('rlk_personal');

        var logger = log('AdGuard');

        alerting.sendAlert('AdGuard Protection is now ' + event.itemState.toString().toLocaleLowerCase() + '.', logger);
    type: script.ScriptAction

is actually stored in the JSON as

  "adguard_protection_alert": {
    "class": "org.openhab.core.automation.dto.RuleDTO",
    "value": {
      "triggers": [
        {
          "id": "1",
          "configuration": {
            "itemName": "AdGuard_Protection",
            "previousState": "OFF",
            "state": "ON"
          },
          "type": "core.ItemStateChangeTrigger"
        },
        {
          "id": "2",
          "configuration": {
            "itemName": "AdGuard_Protection",
            "previousState": "ON",
            "state": "OFF"
          },
          "type": "core.ItemStateChangeTrigger"
        }
      ],
      "conditions": [],
      "actions": [
        {
          "inputs": {},
          "id": "3",
          "label": "Send Alert",
          "description": "Uses the alerting library to send an alert level message",
          "configuration": {
            "script": "var {alerting} \u003d require(\u0027rlk_personal\u0027);\nvar logger \u003d log(\u0027AdGuard\u0027);\nalerting.sendAlert(\u0027AdGuard Protection is now \u0027 + event.itemState.toString().toLocaleLowerCase() + \u0027.\u0027, logger);\n",
            "type": "application/javascript"
          },
          "type": "script.ScriptAction"
        }
      ],
      "configuration": {},
      "configDescriptions": [],
      "uid": "adguard_protection_alert",
      "name": "AdGuard Protection Alert",
      "tags": [],
      "visibility": "VISIBLE",
      "description": "Send an alert when AdGuard protection changes"
    }
  }

I think the root cause here is that naked JSON is not compatible with YAML but the conversion from JSON to YAML doesn’t know it needs to convert the config property from JSON to YAML too. For most other Things, I bet it’s not JSON and doesn’t need conversion to be compatible with YAML.

I can see that they tried to make the JSON be a string with the addition of the " at the beginning and end of the JSON, but because the JSON itself uses " that completely messes it up.

I’m not sure what the best approach is to fix this but do know the solution will either be on MainUI or openhab-core, not on the binding.

I’d start with MainUI with a title of something like: “Thing YAML code fails if config contains JSON”.

apella12 · January 31, 2024, 9:15pm

I did post a github issue, but possibly in the wrong repository.

After some reflection I tested adding a HA config to an existing (3 configs) node and it worked fine (no issue with the status of the code tab). I’m thinking the visible issues on the code tab may be irrelevant. It really can’t be changed anyway (will be overwritten at some point) and I don’t actually want to edit it either. I’m suspecting when a HA config is added the HA discovery resets the node, but when a config is deleted it doesn’t, so a manual delete thing and scan is required. Still an issue, maybe just not related to the state of the code tab. I’m going to poke around a bit more.