Re: 11.3.2.6 MQTT Subscribe (control) Topic

[dbrunt]

Hello Michael,

Trying to use mcsMQTT to integrate HS with HA. I am mostly there (I think) but stuck on the above subject.
I have the devices in HA and they emit a Control topic when I activate them in HA but what do I put here to permit HS to act on the command:



MQTT Explorer shows:


Additional info:



HA Config:

# Homeseer device Kitchen Blind 2
- platform: mqtt
name: "Kitchen Blind 2"
payload_on: "99"
payload_off: "0"
unique_id: "kitchen_blind_2"
brightness_scale: "99"
on_command_type: brightness
brightness_state_topic: homeseer/Z-Wave/Kitchen/Blind 2 Tilt
brightness_command_topic: homeseer/Z-Wave/Kitchen/Blind 2 Tilt/Control
state_topic: homeseer/Z-Wave/Kitchen/Blind 2 Switch
command_topic: homeseer/Z-Wave/Kitchen/Blind 2 Switch/Control
optimistic: false

# Homeseer device Kitchen Blind 3
- platform: mqtt
name: "Kitchen Blind 3"
payload_on: "99"
payload_off: "0"
unique_id: "kitchen_blind_3"
brightness_scale: "99"
on_command_type: brightness
brightness_state_topic: homeseer/Z-Wave/Kitchen/Blind 3 Tilt
brightness_command_topic: homeseer/Z-Wave/Kitchen/Blind 3 Tilt/Control
state_topic: homeseer/Z-Wave/Kitchen/Blind 3 Switch
command_topic: homeseer/Z-Wave/Kitchen/Blind 3 Switch/Control
optimistic: false

# Homeseer device Living Room Window Blind
- platform: mqtt
name: "Living Room Window Blind"
payload_on: "99"
payload_off: "0"
unique_id: "living_room_window_blind"
brightness_scale: "99"
on_command_type: brightness
brightness_state_topic: homeseer/Z-Wave/Living Room/Window Blind Tilt
brightness_command_topic: homeseer/Z-Wave/Living Room/Window Blind Tilt/Control
state_topic: homeseer/Z-Wave/Living Room/Window Blind Switch
command_topic: homeseer/Z-Wave/Living Room/Window Blind Switch/Control
optimistic: false

# Homeseer device Living Room Patio Door Blind
- platform: mqtt
name: "Living Room Patio Door Blind"
payload_on: "99"
payload_off: "0"
unique_id: "living_room_patio_door_blind"
brightness_scale: "99"
on_command_type: brightness
brightness_state_topic: homeseer/Z-Wave/Living Room/Door Blind Tilt
brightness_command_topic: homeseer/Z-Wave/Living Room/Door Blind Tilt/Control
state_topic: homeseer/Z-Wave/Living Room/Door Blind Switch
command_topic: homeseer/Z-Wave/Living Room/Door Blind Switch/Control
optimistic: false

# Homeseer device Bedroom Blind
- platform: mqtt
name: "Bedroom Blind"
payload_on: "99"
payload_off: "0"
unique_id: "bedroom_window_blind"
brightness_scale: "99"
on_command_type: brightness
brightness_state_topic: homeseer/Z-Wave/Bedroom/Blind Tilt
brightness_command_topic: homeseer/Z-Wave/Bedroom/Blind Tilt/Control
state_topic: homeseer/Z-Wave/Bedroom/Blind Switch
command_topic: homeseer/Z-Wave/Bedroom/Blind Switch/Control
optimistic: false

[dbrunt]

More info...

[Michael McSharry]

I am not conversant with HS, but what I see is the following.
1. A device in HS already exists with ref 599 to manage blinds via a switch. This means that HS owns the physical aspects of the transaction.
2. To control the device you currently have the topic Kitchen/Z-wave/Blind_2_switch setup (it could beZ-wave/ Kitchen/Blind_2_switch as I forget if room or floor is first)
3. Device 599 will report its status using the same topic. You do not want this as control and status topics should be different.
4. In HA a devide for Kitchen Blind 2 is setup where it looks as if HA receives the topic

homeseer/Z-Wave/Kitchen/Blind 2 Switch/Control

it will try to act upon a payload of 0 and 99 to turn its virtual status off and on and will report its virtual status on the topic

homeseer/Z-Wave/Kitchen/Blind 2 Switch.

5. I think you want the HA virtual device status change to be treated as a command to the HS physical device. This means your subscribed topic for ref 599 should be

homeseer/Z-Wave/Kitchen/Blind 2 Switch

In the generic (template) case this should be
[/code]
homeseer/$$ROOM:/$$FLOOR:/<<REPLACE($$NAME:," ","_")>>
[/code]
I could have room and floor swapped. I have also not evaluated inline expression in a template. It may be better to be consistent with use of space and underscore between HS and HA so a Replace operation is not needed.
6. When device 599 changes you want the HA virtual device to know about it. This mean the Pub topic should be what HA is expecting for a command or

homeseer/$$ROOM:/$$FLOOR:/<<REPLACE($$NAME:,"_"," ")>>/Control

[dbrunt]

Thanks. I'll need to digest that a little later! 2 beers into the halfway point on Vancouver:St Louis game 1 of playoffs...

[dbrunt]

2: 2 end of 2nd period

[dbrunt]

So, floor and room might be reversed to what I want and I will look at syncing names " " vs "_".
I am using Location 1 = Technology and Location 2 = Room so I now see that Floor and Room are reversed from what I have in HA.
It looks like mcsMQTT is using Location 2 (Floor) | Location 1 (Room) | Device_Name?



BTW...

[dbrunt]

For HS4 version of plug-in & compatibility, may I suggest considering:
Somehow use "Location1" & "Location2" instead of ROOM / FLOOR?
Or indicating in the balloon tip which is which might be helpful.
And perhaps use or mirror the HS4 flag "Display Location 1 first"?

[Michael McSharry]

I think you are correct about Floor/Room/Name order. Floor and Room are used because that is what HS3 uses. HS4 also uses Room and Floor on it's Devices page. The API has Location and Location2 properties. Earlier versions of HS had only one location property. Based upon your screenshot the HS4 user is able to change Room and Floor labels to whatever makes sense to them so the generic Location1 and Location2 would be good.

I'm not that far from BC. I think Seattle is getting a NHL team.

[dbrunt]

I'll play around with my Location1/Location2/Display Location 1 First to see if I can get things organized in HS, mcsMQTT and HA so I can KISS.

[dbrunt]

I worked on this yesterday from around 4pm until midnight but I got 'er workin'...
I sorted out the floor/room/location1/location2/name issues.
I changed from 'light' to 'cover' in HA.
I've got 'tilt' working but had trouble with the on/off switch but it is also now working.
Here's my config:

cover:
 - platform: mqtt
name: "Kitchen Blind 3"
command_topic: "homeseer/Z-Wave/Kitchen/Blind 3 Switch"
state_topic: "homeseer/Z-Wave-Kitchen/Blind 3 Switch/state"
qos: 0
retain: true
payload_open: "255"
payload_close: "0"
state_open: "255"
state_closed: "0"
optimistic: false
tilt_command_topic: 'homeseer/Z-Wave/Kitchen/Blind 3 Tilt'
tilt_status_topic: 'homeseer/Z-Wave/Kitchen/Blind 3 Tilt/state'
tilt_closed_value: 0
tilt_opened_value: 99
device_class: 'window'
tilt_min: 0
tilt_max: 99

image widget

Then I made some more changes and switched to using /cmd and /state and no hiccups and still working!

Thanks for your feedback,
Daniel

[dbrunt]

Something's not quite right...

When I reboot HS, the blinds activate as per the last cmd issued by HA even though I have controlled them afterwards in HS.
How would I stop this or somehow get the HS state and HA cmd's in sync?
Sometimes I control them from HS and the state is fine but the last cmd from HA is processed by mcsMQTT at startup...

[Michael McSharry]

A philosophy of control ownership needs to be established and the the implementation needs to follow that philosophy. In my xAP environment that was setup in the prior decade I considered the owner of the hardware to be where truth exists. There was no single place where truth was owned. In a typical HA or HS environment truth is owned by HA or HS.

in your specific the question is why HA does not know that HS changed the state of this device. I suspect it knows the state has been updated and it will reflect the HS -commanded state in its device status UI. If I am not correct on this then your MQTT topics at present not setup correctly so both HS and HA are in sync.

If I am correct then I suspect that HA believes it owns the state and has setup the MQTT publish for this device to set the retain flag as true. This way if the the subscriber of the topic (HS) is not online when the command is given then the MQTT broker will retain the message and send it when each subscriber comes online. The broker will continue to do this until the publisher changes the message. If you do not want HA to own the state of this device then don’t set the retain flag in the message. Once a message had been retained and you want it to make it no longer retained you need to tell your broker to forget this message. The HA broker and mcsMQTT brokers forget retained messages on its restart. Mosquito persists them through a mosquitto restart. I delete the mosquitto database to remove its retain memory. Google for the procedure for the broker you are using.

Does this make sense?

[dbrunt]

Somewhat makes sense...
I've got HS publishing the z-wave device current value to "state". It is subscribed to "cmd" which is what HA publishes when I change the device from HA. When that happens, HS sets the device as per HA and publishes the new current status back to "state". At that point they are in sync. The problem I've observed is when HS reboots after the device has been changed via HS...
HA last published cmd "99" (or "80" or whatever)
HS last controlled the device with "37" which mcsMQTT published to "state"
HS then boots and sets the device to "99" (or whatever) as per the last "cmd" from HA.

I've changed the HA retention and that seems to have resolved the issue of the blinds changing to the HA last commanded value when HS reboots...

 - platform: mqtt
name: "Kitchen Blind 2"
command_topic: "homeseer/Z-Wave/Kitchen/Blind 2 Switch/cmd"
state_topic: "homeseer/Z-Wave-Kitchen/Blind 2 Switch/state"
qos: 0
[B]retain: false[/B]
payload_open: "255"
payload_close: "0"
state_open: "255"
state_closed: "0"
optimistic: false
tilt_command_topic: 'homeseer/Z-Wave/Kitchen/Blind 2 Tilt/cmd'
tilt_status_topic: 'homeseer/Z-Wave/Kitchen/Blind 2 Tilt/state'
tilt_closed_value: 0
tilt_opened_value: 99
device_class: 'window'
tilt_min: 0
tilt_max: 99

[Michael McSharry]

You do have the option to set the retain flag on the HS side if you believe HS is the authority for the state of the device. This would protect the situation where HA was down and HS changed the device. When HA starts back up the broker would assure HA has the same state as HS. I do not like a lot of startup traffic so I usually do not use the retain. If I was not always doing development testing then I would make more use of retain.

[dbrunt]

I think the mcsMQTT retain flag you're referring to is already set: