autosteve/acmqtt

CBus Automation Controller: Home Assistant, MQTT, Philips Hue and more (for the SHAC/NAC/AC2/NAC2)

acmqtt's Issues

Duplicate discovery topics in logs

Firstly thanks so much for these scripts they made my life so much easier. I set these up in a Spacelogic controller but in the Spacelogic logs I'm seeing 5500AC2 a duplicate removal, it just continues repeating forever for the same objects.

HW: LSS5500SHAC (i.MX6)
SW: 1.14.0

No idea if this is relevant but my devices are 0/56/x in the objects screen

24 22:08:05

• string: Warning: Removing 4 duplicate discovery topics
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_12/config
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_45/config
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_47/config
  MQTT send receive 06.01.20
• string: Removed discovery topic homeassistant/switch/cbus_mqtt_254_56_27/config
  MQTT send receive 06.01.2024 22:08:05
• string: Warning: Removing 1 duplicate discovery topics
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/switch/cbus_mqtt_254_56_28/config
  MQTT send receive 06.01.2024 22:08:05
• string: Warning: Removing 3 duplicate discovery topics
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_7/config
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_13/config
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_44/config
  MQTT send receive 06.01.2024 22:08:05
• string: Warning: Removing 2 duplicate discovery topics
  MQTT send receive 06.01.2024 22:08:05
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_12/config
  MQTT send receive 06.01.2024 22:08:08
• string: Warning: Removing 3 duplicate discovery topics
  MQTT send receive 06.01.2024 22:08:08
• string: Removed discovery topic homeassistant/switch/cbus_mqtt_254_56_27/config
  MQTT send receive 06.01.2024 22:08:08
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_45/config
  MQTT send receive 06.01.2024 22:08:08
• string: Removed discovery topic homeassistant/light/cbus_mqtt_254_56_47/config
  MQTT send receive 06.01.2024 22:08:08
• string: Warning: Removing 1 duplicate discovery topics
  MQTT send receive 06.01.2024 22:08:08
• string: Removed discovery topic homeassistant/switch/cbus_mqtt_254_56_28/config

Cover device states not reflecting 'position' in HA

My cover devices are not reflecting the correct 'state' in relation to their position. Is this controlled/managed in your scripts/discovery? I think HA flipped this recently?

I use window winders on a switch relay to open/close windows.

CLOSED = 0
OPEN = ~255/100%

I also have Blinds on a similar setup

CLOSED = 0
OPEN = 255/100%

Is there a way to ensure correct states are represented in HA so that I can control correctly?

Removing all keywords from a bsensor does not remove the Home Assistant device

This works for all other types (including binary_sensor), but removing a bsensor seems to require the manual removal of the Home Assistant device.

Removing trigger MQTT keyword

Removing a trigger group MQTT keyword is not resulting in removing the MQTT discovery topic for that trigger group.

[Feature Request] Airtopia AC Control

Hi Steve,

Would like to request a feature. I have 2 Daikin AC units that are connected using Airtopia units (I think the company is basically dead now).

My 2 Airtopia units are added to CBUS via Modbus and are in group 250 (I think this is the correct terminology)

In my CBUS webUI, under objects I have the following entries
local/User Parameter/Lounge AC Power
local/User Parameter/Lounge AC Set Point
local/User Parameter/Lounge AC Mode
local/User Parameter/Lounge AC Fan
local/User Parameter/Lounge AC Vertical Swing
local/User Parameter/Lounge AC Protocol ID
local/User Parameter/Lounge AC Temperature Sensor
local/User Parameter/Lounge AC Current Sensor
local/User Parameter/Lounge AC Dry Contact

Is it possible to add these devices to Home assistant? I added the Tag 'AC' to one of the units but in MQTT explorer it showed up outside of the home assistant topic so I couldn't add it.

attached is a screenshot on how they appear in CBUS

I greatly appreciate your work on this, getting my lights added to HA has been a game changer.

Observation on Trigger groups and naming the levels

Hi Steve,
Noticed a little issue, and admittedly I probably caused this as I asked for it originally :)

When discovering trigger groups, if levels are not actually named in the SHAC/NAC on the relevant trigger group, nothing is published,
I think because of this:

  GetCBusLevelTag(net, app, group, level)
  tag = GetCBusLevelTag((tNetAC(net)), 202, group, tonumber(i))
  --log("This Tag is : " .. tag)
  if tag then  -- Will not pass this test if the levels are not named in SHAC...so names have to be declared..
    					 --  
    log("Tag is : " .. tag)
    boid = oid..'_'..i
-- and so on....	

Even when we declare the levels required by adding the keyword tag 'lvl=0-63-127-199-255', if those numbers don't really have names assigned to their respective level number, it does not publish them, and the current logging did not really reveal the reason..

Not really sure of the best solution... a simple fix is to just modify the README with a note to state all required levels have names defined..
Perhaps there is a more robust technical solution?

Personally, I do normally name all my levels, but I stumbled across the 1 out of 27 where I didn't today!

-P

255 items added to MQTT

Would it be possible to have a config item to limit how many MQTT devices are announced via MQTT. I have about 30 devices I can see on my SHAC (connected via TCPIP) but 255 devices and 255 entities are in MQTT in HA

Trigger Control queue stuck

Gday Steve,
I haven't updated the script in a while but changed recently and noticed this problem with updates to a trigger control group.

Device: 5500AC2
Version: 1.15.0, hw v1.1
Script version: da64373

Add trigger control group with keywords: MQTT, select, lvl=0/255, sa=ZZZ

MQTT Send Receive 06.05.2024 11:09:56
* string: Queued 1 object with keyword MQTT for publication: 0/202/11
MQTT Send Receive 06.05.2024 11:09:56
* string: cudCBusTopics() completed in 0.020 seconds
MQTT Send Receive 06.05.2024 11:09:56
* string: Publishing homeassistant/select/cbus_mqtt_254_202_11/config as breakfast in area ZZZ
MQTT Send Receive 06.05.2024 11:09:56
* string: Publishing select cbus/read/0/202/11 to off (0)
MQTT Send Receive 06.05.2024 11:09:56
* string: Published 1 CBus discovery and current level topic

Set trigger control group level = 255

MQTT Send Receive 06.05.2024 11:11:44
* string: Not setting 0/202/11 to 0, same as previous value

Set trigger control group level = 0

MQTT Send Receive 06.05.2024 11:12:40
* string: Setting 0/202/11 to 255, previous=255
MQTT Send Receive 06.05.2024 11:12:40
* string: Publishing select cbus/read/0/202/11 to on (255)

Trying to get autodiscovered fans to show current state

Hi,

I’ve managed to define CBUS fans (that use a CBUS fan controller) in Home Assistant by simply including the tag “FAN”. It is discovered by Home assistant and controllable by home assistant by selecting preset modes to change the speed (low, medium, high) and can be turned off by switching the fan off.

My previous MQTT integration where I had to define the FAN entity manually, the preset_mode was viewable as a state. I am looking for a way to achieve the same with your code so I can use these entities with fan controller cards in Home Assistant, or even just determine the state before I set the fan or even use with automation based on the state.

Updating MQTT objects during CBus ramp to off causes 'last level' issues

It would appear that HomeAssistant is now remembering the last level of MQTT objects, avoiding sending an 'ON' command for full brightness. It's been this way for quite some time.

This is a welcome change, however for CBus via 'MQTT send receive' it causes level issues when a CBus 'ramp off' command is used (something which HomeAssistant does not grok). So what ends up happening is that HomeAssistant will remember the last non-zero level that it received during the ramp. This results in the light turning on later at a very low level if done from HomeAssistant.

Potential for multiple queued CBus messages to skip setting 'final' flag

In the case where two lighting groups are simultaneously changed there is the potential for the final flag in outstandingCbusMessage() to not be set correctly.

Name passthrough inconsistent when used with sa

I've noticed that if the sa is one word then the area is omitted from the name in HA, but if it's two words it's passed through. I'm not sure if this is on the HA side or the script 🤷

My pref is the fullname is always passed through.

MQTT, light, sa= Lees Office, pn=Lees Office Lights, img=mdi:light-recessed,
MQTT, light, sa=Ensuite, pn=Ensuite Lights, img=mdi:light-recessed,

I've tested with a couple of lights to confirm the behaviour

Hue ramp off not working

An issue has been introduced in HUE send receive that prevents a CBus ramp off working correctly.

group application override results in duplicate entities in HA

Hi,

When changing the default application (ie: light) via tags (One of light, fan, cover, select, sensor, switch, binary_sensor, bsensor or button), I end up with two entities per CBUS Group

eg:

light.cbus_mqtt_254_56_27
switch.cbus_mqtt_254_56_27

This exists for temperature sensors, fans, switches, covers.

The order in which I established connection was

1. enable your scripts,
2. enable MQTT keywords across all cbus groups (scripted)
3. enable additional keywords for application and other elements (icons, primary name)

I was expected the discovery capability to manage this as I cannot delete the duplicate entities still with light. in HA as its controlled by discovery.

Additionally, I noticed when I updated CBUS names in CBUS Util, exported CBL file, deleted changed groups in SHAC object list and imported in replacement objects into SHAC, it didnt update in HA either. It still shows original name.

Is this a discovery issue?

I've tried deleting all objects in SHAC and reimporting clean CBL, applying keywords.. no change.

I'm running
5500SHAC
HW: 5500SHAC (i.MX28)
SW: 1.11.0

Home Assistant
Home Assistant Core
Installed version
2022.10.5

Support for firmware 1.15.0+

Nice work with the scripts!!

Maybe related to the cleanup of issue #18 , when ramping from 255->0 the previous level in storage is not updated, preventing a subsequent ramp up from 0->255 being published.

Script version: current
Device: 5500AC2

Log extracts:
Light turned off/on without ramp, all OK.

MQTT 07.01.2024 15:40:23
* string: Setting 0/56/36 to 0.000, previous=255.000
MQTT Send Receive 07.01.2024 15:40:23
* string: Alias: 0/56/36, payload: 0, ramp rate: 0, target level: 0
MQTT Send Receive 07.01.2024 15:40:23
* string: Publishing state and level cbus/read/254/56/36 to OFF/0
MQTT 07.01.2024 15:40:32
* string: Setting 0/56/36 to 255.000, previous=0.000
MQTT Send Receive 07.01.2024 15:40:32
* string: Alias: 0/56/36, payload: 255, ramp rate: 0, target level: 255
MQTT Send Receive 07.01.2024 15:40:32
* string: Publishing state and level cbus/read/254/56/36 to ON/255

Light turned off/on with 4s ramp rate.

MQTT 07.01.2024 15:41:30
* string: Setting 0/56/36 to 0.000, previous=255.000
MQTT Send Receive 07.01.2024 15:41:30
* string: Alias: 0/56/36, payload: 0, ramp rate: 4, target level: 0
MQTT Send Receive 07.01.2024 15:41:30
* string: Set ramp for 0/56/36 and suppress zero send
MQTT Send Receive 07.01.2024 15:41:39
* string: Publishing state and level cbus/read/254/56/36 to OFF/0
MQTT Send Receive 07.01.2024 15:41:39
* string: Removing orphaned ramp for 0/56/36
MQTT 07.01.2024 15:41:41
* string: Not setting 0/56/36 to 255.000, previous value is 255.000

Bug in logic in check for duplication of discovery topics

Hey Steve,
Hope all is well! I upgraded to the latest version of your code today, and have found a little bug I think. I don't fully understand it, but I have managed to kludge a fix for it. I'm unsure if I'm fixing it correctly though, so I won't do a PR..., maybe you can look into it when you have time.

It's in "MQTT send receive", in the function "client.ON_MESSAGE = function(mid, topic, payload)"

This is how i found/fixed it:

client.ON_MESSAGE = function(mid, topic, payload)
  -- Record discovery topics to check for duplication
  local parts = string.split(topic, '/')
  log(parts) -- added by me
  if parts[1] == string.split(mqttDiscoveryTopic, '/')[1] then
    if discovery[parts[3]] ~= nil and discovery[parts[3]] ~= parts[2] then
      discoveryDelete[parts[3]..'/'..parts[2]] = true
    else
      -- check for nil
      log('Part 3 is : ' .. tostring(parts[3]))  -- added by me
      log('Part 2 is : ' .. tostring(parts[2])) -- added by me
      	if discovery[parts[3]] ~= nil then -- added by me
      		discovery[parts[3]] = parts[2] -- Dictionary of CBus addresses with type as the value
      	end -- added by me
    end
  else
    mqttMessages[#mqttMessages + 1] = { topic=topic, payload=payload } -- Queue the MQTT message
  end
end

Sometimes Part 3 can be nil, as homessistant publishes a message on this topic as only "homeassistant/status" and the logic errors out when trying to access the third part as it's not there... I don't really understand why the logic in one of the earlier "IFs" doesn't catch this... something to do with the order or precedence of lua maybe..

I kludged it by checking it again for nil in the ELSE block...and it does work and allow the code to run.... but I suspect i'm missing the bigger picture, I might be breaking something else you intended...

Paddy

Sensor type 'bsensor' discovery code issue

Read undeclared globals 'on' and 'off'. Should be _L.on & _L.off

Refactor key parts into user library?

Steve,

I wonder if it's worth considering taking the common parts of your entire bag of scripts (and the zigbee stuff), and roll it up into a user library?

For example, walking through the list of cbus groups and extracting tags and values, updating that in memory, your new approach to using localbus - all probably generalisable?

Just a thought!

Edge Case: Error occurs if C-Bus group exists, but never had a level set (.i.e is nil)

The error comes from : 'MQTT send/receive'

Can happen after SHAC reboots, or if you create a new object from the SHAC and don't give it a value.
(once you set group to any value 0-255, the error does not occur anymore)

SHAC Error Log:

Library cbuslogic:0: unable to decode for 0/56/30 stack traceback: [C]: in function 'error' Library cbuslogic: in function '_GetCBusLightData' Library cbuslogic: in function 'GetCBusLevel' Resident script:759: in function 'outstandingPublish'

line 759 is :
else publish(tNetCBus(u.net), u.app, u.group, GetCBusLevel(u.net, u.app, u.group))

so it's probably the 'GetCBusLevel' function...

Support for Binary Sensors?

Hey Steve, would it be possible to include the ability to create binary sensors in Homeassistant from C-Bus groups?

Use case:
I have some PIR sensors (non C-Bus types) integrated via a 4ch C-Bus Aux input, configured as bell-push inputs. If the standard electrical grade PIR senses motion, it closes the contact, activating a C-Bus lighting group. I have other scripts/functions in NAC/SHAC that act on the state of this group to do 'stuff'. When motion ceases, PIR opens contact, C-Bus group goes to Zero. Pretty simple.

I can expose these kinds of groups as switches in HA, but people can then mess with their state and turn them on/off (via HA), which I don't want. It would be cool if we could expose them as binary sensors, making them effectively read-only in HA.

For bonus points, a way to configure the group state text would be very cool, e.g 0="No Motion", 255="Motion Sensed".
This could open up multiple options for other integrations, door sensors, window sensors etc..basically anything u might monitor in C-Bus via Aux units...

• Paddy

PS - i don't know how to apply labels! but please mark this as a feature request...

CBUS PIR sensors as binary / lux entities?

Hi,

Is it possible to expose cbus pir sensors ? I believe occupancy (motion) and lux levels may be available?

Ramp tracking HUE is damn near impossible

Ramp tracking frequently gets lost. It does this because messages from the HUE event stream often do not arrive in a timely manner, hitting timeouts in the script for ignore HUE, and the final level messages. This will be because bulbs are sometimes lazy in reporting their current status to the bridge, and often VERY lazy.

If timeouts are increased, then doing one thing involving a CBus ramp, and then another that doesn't will likely result in unexpected behaviour.

For now I have no alternative but to disable ramping/transition of all my Hue devices, and turn my back on some quite complex tracking code.

For the future I hope to get my head around how I can solve this problem.

Do I treat CBus as authoratative, and update it for expected Hue events with a big timeout? If so, how do I know that a difference of opinion when a message fails to come in as and when expected isn't generated by something done in the Hue app or HomeAssistant?

Or implement a MQTT-style read/write semanic? Events received from Hue update the CBus GA without the script trying to publish that again to Hue? Yeah, that's what I'm doing already with the script, but in a different way.

Possibly do not use the HomeAssistant Hue integration, and avoid the app. That could work, using MQTT and discovery to publish, but would prohibit things that the app and HomeAssistant do well and CBus doesn't do, like colour temperature. (Or only do colour temperature in the app?) That and folks will obviously use the HA integration, because it's just better at things, has a massive ecosystem of diverse device support, and is usually the main game, unlike me where CBus/visualisation/DLTs are the main game, and HA is a nice-to-have-interface-to-haaaay-goooogle and to see how much fuel the car has on board...

There be dragons with Hue/CBus transition sync.

HA friendly_name problem

Gday Steve, this definitely in the low priority list.

I was tinkering in HA and found the following with friendly name.

Device: 5500AC2
Version: 1.15.0, hw v1.1
Script version: dd6c72b

--[[ SET AS APPROPRIATE TO SUIT ENVIRONMENT --]]
all false

Lighting GA, add keywords: MQTT, cover, noleveltranslate, sa=ZZZ, img=mdi:roller-shade,
HA friendly_name has a space character appended to the tag name.

friendly_name: "ext blind 6 "

Lighting GA, add keywords: MQTT, cover, noleveltranslate, pn='ext blind 6', sa=ZZZ, img=mdi:roller-shade,
HA friendly name includes the quotation marks.

friendly_name: "'ext blind 06'"

Lighting GA, add keywords: MQTT, cover, noleveltranslate, pn=extblind6, sa=ZZZ, img=mdi:roller-shade,
HA friendly_name has a space character appended to the end.

friendly_name: "extblind6 "

Device connectivity tests are broken

Testing for conectivity in status messages, and not zigbee_connectivity messages. If a device is unreachable then also need to revert the CBus level to its previous value.

Removal of 'select' on Trigger group throws an exception

Discovered by accident trying different options. I didn't like select anyway so not using now.

Create new tag under Trigger Control (202): Test trigger.
Create new levels under Test Trigger: 0=off, 255=on
Add keywords to object Test Trigger: MQTT, select, lvl=0/255, sa=ZZZ, pn=testTrigger,
Remove keywords from object Test Trigger.

Device: 5500AC2
Version: 1.15.0, hw v1.1
Script version: 1c11ad1

MQTT final config
lighting = {['99']=true} -- lastlvl is disabled

Log extract, the 'Error checking' entry is repeated every 30 sec.

* string: Error checking create/update/delete: [string "Resident"]:1223: bad argument #1 to 'ipairs' (table expected, got nil)
* string: Published 1 CBus discovery and current level topic in 0.019 seconds, event scripts restarted
* string: Publishing homeassistant/select/cbus_mqtt_254_202_15/config as testTrigger in area ZZZ
* string: Queued 1 object with keyword MQTT for publication: 0/202/15

Temperature Sensors no longer being discovered in HA

After recent upgrades (am unsure how to reference what version of send receive script, as this has been removed along with the changelog), my temperatures sensors no longer get discovered/created in HA. I have deleted MQTT in HA and re added to rediscover and there seems to be some odd behaviour.

Events are being published to MQTT.

MQTT published events
cbus/read/0/228/34_1/level

CBUS object keywords
All, MQTT, sensor, unit= °C, dec=1,

Changing a GA from button to switch/light causes status to not be published

A variable 'lightingButton' is used to indicate whether MQTT status should be suppressed. If the GA is subsequently changed to a light or switch, then the GA should be removed from lightingButton.

A work-around is to disable/enable MQTT send receive resident script.

Automation controller ramping is 'interesting', and does not operate the same as Hue transitiontime

Scenario: Ramp a CBus lighting object from 127 to off over twelve seconds. The light takes much less than twelve seconds to turn off as the ramp rate appears to be the time needed to get from 255->0 (so half the ramp time occurs when set at 127, or off in six seconds).

Philips Hue does not operate in this manner. Rather, a transitiontime of 12 seconds means make the transition over 12 seconds.

The impact of this for faster ramps, where the current level is for example 63 and ramp is four seconds, is to reach zero in the automation controller well before the transition finishes for Hue. This is often resulting in ramps being orphaned by the 'HUE send receive' script. It usually does a good job of tracking the ramps, but status updates for short ramps do sometimes cause trouble.

I know that there is a bug in NAC/SHAC firmware 1.10.0 and 1.11.0 (reported by me), where event-based scripts that are set to not execute during ramping actually do. This worked in 1.6.0, and broke around 1.10.0. It will be fixed in a future firmware release. Once that bug is fixed then I can likely improve the synchronisation by adding a second 'HUE final' event-based script set to not execute during ramping, which would be able to signal to 'HUE send receive' that a ramp has actually finished on the CBus side.

My scripts require 1.10.0+ firmware, so I cannot simply downgrade. I will mention that fact in the README.md as it is missing.

I can develop this today, as my primary controller is a NAC on 1.11.0, but I also have a SHAC on 1.6.0. Others will not have that luxury, so will need to wait for the execute during ramp bug to be fixed to get more predictable operation for short ramps that are from lower starting levels.

I am still mulling over whether I should mathematically adjust the Hue transitiontime to approximate the actual CBus ramp. That might make sense.

Will stop working in Home Assistant in v2024.2.0

Home assistant has a warning that the MQTT devices will stop working and to let the maintainer to know.

---

Discovered MQTT entities with a name that is equal to the device name
This stops working in version 2024.2.0. Please address before upgrading.
Some MQTT entities have an entity name equal to the device name. This is not expected. The entity name is set to null as a work-a-round to avoid a duplicate name. Please inform the maintainer of the software application that supplies the affected entities to fix this issue.

List of affected entities:

(Lists all my cbus devices)

https://developers.home-assistant.io/blog/2023-057-21-change-naming-mqtt-entities/

Support for Trigger Control - Application 202

Hey Steve -
Not sure if you are open to requests? Thought if I didn't ask, I'd never know 😊

Is it possible to support the Trigger Application? I have a bunch of C-Bus scenes that are triggered by Trigger groups and action selectors. The scenes themselves are stored in various c-bus switch units, and sometimes the SHAC itself. All works perfectly inside C-Bus world...

I know HA also has scenes, but it would be very handy to be able to re-use and trigger existing C-Bus scenes via this integration.

Ultimately, it's just a group number that has a 202 address instead of 56, where you set the preset level to some value between 0 and 255 to trigger the scene you want. I was thinking of something like representing them in HA as switches or toggle buttons perhaps. I only need to trigger them, no need to edit the scenes, store new levels or any of that – just somehow trigger what I already have....

More than happy to help with any testing needed. My Lua code abilities are rudimentary (at best!) but I can read and grasp most of it....

Let me know? If it's too much hassle, feel free to close this ticket...

Paddy

Sensors from the lights application sending state

Not sure if this is working as intended:-
I have a group address under the lighting application, which sets a level based upon what the current security mode is. (I don't know why I did it this way, it was a while ago).
If I define this as :-
MQTT, sensor, pn=SecurityMode
I get a sensor device in Home Assistant. When I change security modes, I can see a MQTT message with the correct level being sent out with an additional STATE value. Looks like Home Assistant is only tracking the STATE value in the payload.