-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Option for non-JSON output #493
Comments
I think this is a good idea:
i would prefer another topic signature: |
I can only agree to that. Don't make the payload overly complicated by adding json. |
@cimba007 JSON output is required for homeassistant integration. However I will add an option to disable this. |
I've been testing these changes and it seems to work well so far. I can make a PR with the referenced changes if it seems like a reasonable way to do it to you. |
That could give you some inspiration: https://homieiot.github.io |
Great choice! The new MQTT binding in openHAB supports the Homie convention and would allow openHAB users to discover MQTT devices rather than having to manually enter them in openHAB. |
This would be a great feature (changing between JSON and separate topic). I am using openHAB and Zigbee2MQTT to bind Osram, Ikea and Xiaomi stuff. The new (faster and enhanced) MQTT binding is not working very well on formatting JSON for outgoing stuff. Is this feature ready for testing? |
I don't think a "real" implementation of the homie convention (and thus supporting the OH 2.4 MQTT auto discovery for example) has been considered/planned in this project yet. That would be quite some effort I guess. |
For the first step the feature described by rachetfoot:
would be a great help for all openHAB users. Now sending a JSON payload like
Now Zigbee2MQTT should accept these payloads insted of JSON messages. Adding the homie convention to Zigbee2MQTT would be great, too. |
My change is quite naive and only handles a single level object, converting all properties of that object to topic/message pairs. It works fine for my purposes, but to be honest, I don't think it's robust enough for merging. And with what I now know about the homie convention, I think I would prefer scrapping my approach and implementing that convention instead, however that will require a much larger effort and probably also changes to the way devices are defined. |
Is your change working as described in my assumption above? How can I implement it? |
I haven't tested, but I expect that it would publish something like this: And react to a similar message sent to zigbee2mqtt/mydevice/color/set If you wanted to test and/or develop, you would just have to add my repo (rachetfoot/zigbee2mqtt) as a new remote where you installed it originally and then checkout the branch I made with the changes. (Also stop service before doing so and start again afterwards) |
Should we open a new issue to discuss this as a request (implement the Homie convention)? |
Up to you. However, I would like to hear whether @Koenkk is even open to this change. |
What is the homie convention? |
|
Looks good! I think it's nice to have this in zigbee2mqtt. |
Cool, how can I help? |
@rachetfoot opt/zigbee2mqtt/node_modules/zigbee-shepherd-converters/converters/toZigbee.js:42 TypeError: value.toLowerCase is not a function |
Yeah, I had that issue too, and I'm not sure why because it works in the tests. However, this still works: |
Yes thx. This Is working |
👋 I tried the homie path - highly experimental: #855 I think zigbee2mqtt might need some changed to support plugins that act on prepared messages (before toZigbee / after fromZigbee). This would simplify custom MQTT hierarchies a lot. |
Good Job. |
I haven't tested non-RGB lights yet, that's on my to-do towards end-of-week.
There is a big block that looks at JSON keys (look for e.g. 'illuminance')
that would likely need some additions.
Am Mo., 14. Jan. 2019, 09:25 hat Luftloch80 <notifications@github.com>
geschrieben:
… Good Job.
Working with My Osram Plug, but the Osram Classic Light only Publishes
this two values
No on/off or brigntness
zigbee2mqtt:info 2019-1-14 08:22:31 MQTT publish: topic
'homie/0x8418260000073d64/$stats/uptime', payload '180'
zigbee2mqtt:info 2019-1-14 08:22:31 MQTT publish: topic
'homie/0x8418260000073d64/$stats/interval', payload '60'
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#493 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADveuPGpvDMkGSWGWFoLrwu1K90TPV2ks5vDD7xgaJpZM4XoWSl>
.
|
Okay. Because when i Pair the Bulbs in ioBroker they work normally |
These are the payloads i get mosquitto_sub -h localhost -t 'homie/0x8418260000073d64/#' string |
Hi Newborn zigbee2mqtt user here. I'm using Openhab2 2.4, and was reading that Openhab2 does not support output formatting for JSON. I modified a python mqtt script from https://pypi.org/project/paho-mqtt/ to accept non-JSON data from openhab and format it as JSON The reverse scenario should be possible as well so that one could decode json data into separate topics. I have not tested it on my own installation yet, just on the pc and on the global iot.eclipse.org broker. Sorry about the messy looking code block, it's one of my first posts... The data flow is: Cheers `import paho.mqtt.client as mqtt The callback for when the client receives a CONNACK response from the server.def on_connect(client, userdata, flags, rc): The callback for when a PUBLISH message is received from the server.def on_message(client, userdata, msg): client = mqtt.Client() |
I just tried the script and can confirm, it works. mosquitto_pub -h 192.168.1.160 -m 25 -t zigbee2mqtt/0x000b57fffeab3e34/brightness Hope this finds its use somewhere, until either zigbee2mqtt might include a non JSON format or Openhab2 2.5 is released. Cheers |
@stoinov I've made a first implementation, you can enable it with experimental:
output: attribute Let me know if it works out for you. |
@Koenkk I got:
but after this I saw all the payloads as simple strings in their respective topics. So great initial step! Another thing I noticed |
Home assistant discovery and output attribute cannot be used together (as the home assistant discovered configuration is not compatible). We can change that too. |
Two questions:
I don't have a light to test, but from the code it seems like only the first level of attributes are reported and there is an object it's still passed as JSON. This should be easily fixable. I am just wondering whether to add another level to the topic like Both have their pros and cons, and I personally use the second approach with the ESPHome reports, as it makes it easier to handle various inputs without adding too much exception logic in my scripts. Besides it all goes to DB where it's flattened anyway. |
|
* Expand attribute output. #493 If attribute is actually an Object, expand it in the format `topic/key-subkey` in order to keep the same amount of topic levels for predictable parsing. This only expands the first level of contained object. If more expansion are needed a more robust method should be implemented rather than just nesting `if`s. * Fixing whitespace fixing https://travis-ci.org/Koenkk/zigbee2mqtt/builds/507616980 * first time splitting line... obviously Not sure what the proper approach is, but I guess we can put all params on new line. * identation... really... How is that `eslint`? any other requests?
I do not understand your concern about the discovered configuration. Can you elaborate? |
BTW I should probably update documentation too explaining the new behavior... |
@stoinov because now all the attributes are reported to a different topic, so e.g. https://github.com/Koenkk/zigbee2mqtt/blob/master/lib/extension/homeassistant.js#L114 won't work anymore. |
I see. So we need couple of Regardless, we'd have to convert the values to RGB with something like this. I know it's quite the change, and most of it I think I can manage myself, but I would definitely need some help understanding some of the architectural decisions. |
I don't think adding discovery configurations for both JSON and attributes output is a good idea:
There are also options to control via RGB: http://www.zigbee2mqtt.io/information/mqtt_topics_and_message_structure.html#zigbee2mqttdevice_idset I think a better solution here would be to have a |
I agree with you that it will be a lot of extra maintenance, but only if we want to have the light as an attribute. The optimal solution, would be to leave all light objects as JSON payloads even with attribute option. Looking at the configurations list, only the lights section has composite payload - all other objects are single level with one entry. We can still implement double output but I don't like this solution as our primary option since it would look and feel clumsy, especially when you try to debug MQTT. In the RG link this explains setting up, but can you actually report in RGB or HS? There is no specific setting in the configuration list with lights, only two include XY. |
That doesn't sound like a good solution me, because the light objects still have to be JSON. The reporting is indeed in XY, as this is what zigbee uses. EDIT: What I'm wondering about, what is your use case to use both non JSON output and Home Assistant? |
I am trying to setup home automation without actually using Home Assistant - just node-red parsing the MQTT payloads and inserting them into InfluxDB. Going back to the request though - my whole idea is to leave the light as a JSON object and just skip the reporting of the But as I said - it's not high priority any more and we can leave it as it is. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
* Expand attribute output. Koenkk#493 If attribute is actually an Object, expand it in the format `topic/key-subkey` in order to keep the same amount of topic levels for predictable parsing. This only expands the first level of contained object. If more expansion are needed a more robust method should be implemented rather than just nesting `if`s. * Fixing whitespace fixing https://travis-ci.org/Koenkk/zigbee2mqtt/builds/507616980 * first time splitting line... obviously Not sure what the proper approach is, but I guess we can put all params on new line. * identation... really... How is that `eslint`? any other requests?
This is really useful for openHAB integration. Do you plan to make this from experimental to "advanced" |
@olialb this feature will stay in for sure, not sure if it's well tested enough atm though. |
I've been using it for months now without issues. |
I've been using it almost a year, so it's stable. But I do not have much experience with setting it up in different environments, so not sure if we have some edge cases that could break it, so any feedback is welcomed. I use this exclusively, without HA obviously. Any other cases? |
I am using it with openHab and it runs stable. Make the setup much more easy.... |
I used this feature for read-only attributes, but now I have an IKEA light bulb and would like to control it without using json. Is it possible?
How about transitions, if it is no longer a single json(/transaction) it would be hard to do transition to given state, so how it is handled right now? I know that the setting for that (and this issue) is about |
zigbee2mqtt/[FRIENDLY_NAME]/set/brightness seems to work. zigbee2mqtt/[FRIENDLY_NAME]/set works with with ON|OFF payload. Although this works also without "output: attribute" entry in the configuration. |
Hello all,
in my |
figured it out. For everybody facing the same: |
This is more of a general question: would it be feasible to add option so that each attribute to be separate entry on the MQTT path. So instead of:
zigbee2mqtt/0x00158d0002219 {"battery":"39.00","voltage":2995,"temperature":18.87,"humidity":60.87}
We get:
I am trying to setup my own automation without actually using HA, and I hit a roadblock with the homebridge setup - it does need simple strings to work, so I have to parse the JSON and republish them to make it work.
The text was updated successfully, but these errors were encountered: