Announcement

Collapse
No announcement yet.

Beginner

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Your log shows the homeassistant/sensor/... and homesasistant/light/... topics which give mcsMQTT the information it needs to create HS devices. Device creation occurs when the topic ("state_topic") "zigbee2mqtt/0x14b457fffed111a9" is published. This topic should be published by zigbee2mqtt when it sees a change in the state of the light as it is turned on/off. on/off. This step 10 event of turning the light on/off was not in the log. The log ended 30 seconds after then homeassistant topics.

    If one was to look at the Association tab of mcsMQTT I would expect multiple entry for zigbee2mqtt/bridge/state and multiple entries for zigbee2mqtt/bridge/log and zigbee2mqtt/bridge/config to exist. I think you indicated that this did happen.

    The things that could prevent mcsMQTT from logging the step 10 "zigbee2mqtt/0x14b457fffed111a9" topic if the topic was actually published is if the mcsMQTT is configured for the topic to be rejected (General tab Reject textbox) reject text"R" column on Association tab). It could also be discarded because the payload is empty or if the topic is a topic that has been setup to be published by mcsMQTT.

    Are you not able to run both HASS and HS at the same time or use something like MQTT Explorer to get an independent assessment if zigbee2mqtt does publish "zigbee2mqtt/0x14b457fffed111a9" at step 10?

    Comment


      #17
      I did use MQTT Emplorer andwhat I saw was that zigbee2mqtt created the homeassistant topics at which point HASS created the device and Homeseer did not.

      Comment


        #18
        HASS creates device when homeassistant topic is received. mcsMQTT saves the homeassistant topic information so that when the topic is seen it will know what type of HS device to create and will be able to populate the device's value in HS based upon the payload that came with the message.

        If only the homeassistant topic is published then there is no reason to create HS devices because no value for that device has yet been published.

        The point is that zigbee2mqtt needs to publish the topic showing the state of the light. This needs to occur after homeassistant topic has been published. The homeassistant topic describes how to interpret the data in the state topic. The state topic reflects the properties of the light.

        Comment


          #19
          Got it. I didn't think about running HASS and HS at the same time. Once I used HASS to "control" the light, the topic was created and HS picked it up. So the outcome is that there is an issue with zigbee2mqtt in that it is not publishing the topics.

          Comment


            #20
            I had a similar issue for a inner bulb last week.
            My solution was to use MQTT Explorer to publish zigbee2mqtt/[FRIENDLY_NAME]/get with an empty {"state":""} json payload.
            On the response mcsMQTT populated the device. Maybe easier if one does not have hassio running.


            Comment


              #21
              Originally posted by aarpi3 View Post
              I had a similar issue for a inner bulb last week.
              My solution was to use MQTT Explorer to publish zigbee2mqtt/[FRIENDLY_NAME]/get with an empty {"state":""} json payload.
              On the response mcsMQTT populated the device. Maybe easier if one does not have hassio running.

              I thought about that. Running HASS at the same time is a little easier because it creates a device that I can just flip on then off to get the topic created.

              I added an issue to the zigbee2mqtt github repo so I will see what they say.

              Comment

              Working...
              X