MQTT support

1

leonmeijer ●

Any update on MQTT support?

URL

1

Peter Hesselgren ●

MySensors and MQTT support in Zipabox ?

Or is it time to get a Vera box and sell Zipabox?

Best regards to Zipato for all information here on this forum..........

URL

1

Peter Hesselgren ●

Any news?

URL

1

Leon Meijer ●

Yes indeed, any update?

URL

1

Peter Hesselgren ●

MQTT Hello Zipato

URL

2

Sebastian Popovic ●

Not yet published due to other priorities. For sure it will be published before this summer.

URL

1

Erik S. ●

Is it summertime? :) Any news on MQTT support?

URL

1

Leon Meijer ●

I marked June 21 in my calendar for the beginning of summer and for Zipato MQTT support

URL

1

Peter Hesselgren ●

This year?

URL

1

Peter Hesselgren ●

MQTT Hello Zipato

URL

1

Peter Hesselgren ●

MQTT Hello Zipato

Best regards

Peter Hesselgren

URL

1

Peter Hesselgren ●

Mqtt support?

Sebastian wrote 5 months "For sure it will be published before this summer."

Summer 2017?

.......

URL

3

Leon Meijer ●

Zipato is overpromising and underdelivering, combined with poor communication.

URL

1

Beat ●

In today's update notes for beta version: MQTT: add mqtt network.

Someone has more information about this?

URL

1

Lubos ●

Hi. I would like to have some informacion about MQTT : add mqtt network. Is it automaticly or I must set it in zipabox. I didnt find new button or function. Thank you

URL

1

Oddvar S. Næss ●

Any news on MQTT support? This would be hifghly appreciated.

URL

2

Stefan ●

The MQTT protocol implementation is under development.

URL

1

David Pritchard ●

This is good news because the Roomba 980 has just changed to MQTT and broken my Zipabox integration :-(

URL

2

Alex Kritikos ●

Stefan, any indication of progress? Seriously if you are stuck with anything email me i can help. I am on the OASIS TC for MQTT.

URL

1

Robert Herter ●

MQTT Support would be the to wanted Feature for me.

Any news about this ?

URL

1

Robert Herter ●

I have read in an other Thread that MQTT support ist almost ready.

MQTT only possible to sent to or even to set Values/Control devices ?

URL

2

Stefan ●

Dear Robert,

the MQTT implementation is still in development and will be published for sure, yet I can't tell you the exact date when we plan on releasing the improvement. Please keep an eye on our community forum.

Best regards,

Stefan

URL

1

Adrian Brown ●

Any updates on mqtt?

URL

1

Nicklas Simberg ●

Would be nice with a update on this.

URL

1

David Pritchard ●

Thanks for the info.

URL

1

Robert Herter ●

Any news here ?.

MQTT is working for Zipatile-Sensors already. Any timeframe for MQTT of all Sensors and Devices based on MQTT ?

URL

1

Alberto Macias ●

Looking forward for this feature, hope we can get some news soon...

URL

1

Beat ●

Yes would be really cool to get more information about this...

URL

2

Sebastian Popovic ●

Using MQTT is currently possible only through Zipato API. You can use it in following way:

you do POST /networks with this config:

{
"className": "com.zipato.network.mqtt.MqttNetwork",
"name": "I need inspiration",
"broker": "tcp://brokerip:1883",
"qos": 2,
"clientId": null,
"username": "username",
"password": "password",
"topicBase": null,
"topicPrefix": null
}

About parameters: broker, qos are obvious (I hope).

You'll need to set username & password if you set it on broker.

Code that handles other parameters:

String effectiveClientId = clientId != null ? clientId : ZipatoHelper.getSerial();
String base = topicBase;
if (base == null) {
base = "/";
}
String prefix = topicPrefix;
if (prefix == null) {
prefix = effectiveClientId + '/';
}
root = base + prefix;

After you do that and sync, you'll receive updates on your broker.

I recommend Mosquitto. https://mosquitto.org/

Mqtt-spy also works for us. Just subscribe to /# and see what's happening.

You'll get attribute updates on

/${root}/attributes/${uuid}/value

You can set attribute by sending json to

/${root}/request/attributes/${uuid}/value

or by sending text to

/${root}/request/attributes/${uuid}/textValue

Also, these could be useful...

/${root}/request/networks/${uuid}/status
/${root}/request/devices/${uuid}/status

URL

1

Fredrik Winkvist ●

I'm probably doing something wrong but I can't seem to set attributes in the way you describe.

I've set up the MQTT network with root "zipato/" and prefix "zipabox/" and I can see that the broker receives the messages like the following:

zipato/zipabox/attributes/[GUID]/value {"value":true,"timestamp":"2017-09-25T19:10:44Z"}

I tried to publish a message like the following;

mosquitto_pub -t "zipato/zipabox/request/attributes/[GUID]/value" -m '{"value":false}'

The message is received and displayed in the console but it has no effect.

Can you please provide an example of setting an attribute?

URL

1

Peter Obel ●

I have been working on this too in order to integrate Zipato with other control systems, during my tests I have found that the Zipabox does not subscribe to zipato/zipabox/request/# (no matter what root you have set)

it subscribes to "request/#"

So your command should work like this:

mosquitto_pub -t "request/attributes/[GUID]/value" -m '{"value":false}'

A really good broker to test with is the bevywise because it has a webinterface that lets you see current subscriptions.

Additionally bevywise has a rules engine that I am testing now, the idea being I can link other mqtt devices to zipato virtual devices directly in the broker. I should probably do a full writeup when I am done.

URL

1

Fredrik Winkvist ●

Thank you Peter, I'll check it out!

URL

1

Fredrik Winkvist ●

@Peter, I forgot to follow up on this topic but it is working perfectly now. I've created a simple JS API for voice control on Android. It takes as input STT from the voice service, interpreting the scentence via wit.ai and then executes the actions on the zipabox through MQTT. The only thing I haven't figured out is how to run a scene through MQTT, is it possible?

@Dmitry, that code only shows an example on how they make up the topic from the MQTT network variables, nothing that you need to insert anywhere. For zipabox, all you need to do is to add the network, I'm not using zipatile myself so I'm afraid I can't answer to that.

URL

1

Innodron ●

This method is working with Zipabox but not with Zipatile. Yes, the method adds the MQTT network to Zipatile, but Zipatile does not publish anything to the broker.

On the other hand, the method described here (https://community.zipato.com/knowledge-base/article/internal-app-mqtt-client-documentation) enables Zipatile to publish to broker, however this operates only with Zipatile internal devices - no virtual, Z-wave or Zigbee device information is published nor can be updated through MQTT

I guess the MQTT codebase for Zipabox and Zipatile are not quite aligned yet.

URL

1

Robert Herter ●

I could confirm this, works only for zipabox, not for Zipatile.

But it't a step forward.

And be careful, deleting the MQTT-Network is not possible.

URL

1

Alberto Macias ●

Good to know, thanks for the heads up.

Question for Zipato, this configurations will allow Zipabox to publish and suscribe to topics using another broker, will Zipato controlles will be able to be used as brokers (servers)?

URL

2

David Pritchard ●

Out of curiosity, how are you guys using MQTT with the Zipabox? I know next to nothing about it, except that my Roomba now uses MQTT, apparently.

URL

2

Adrian Van Der Heijden ●

i'm with you david, I see many developers starting to use MQTT, but haven't the knowledge yet. I have another employee looking into it now so hopefully I can understand it better.

Anyone tried the Conrad Connect platform yet?

URL

1

Attila Hajdu ●

I tried conrad, but it seems only solution for sensors. I was unable to switch any lights via conrad as I did not find any actuators.

URL

1

David Pritchard ●

I'd just like to know: what's it good for? Give us an example of what you're doing with it, please :-)

URL

1

Ruud Boon ●

Same here on the Zipatile, New network but no updates from my MQTT broker. Hopefully they will add this soon.

URL

2

TheMeerd ●

Hello Everyone,

I was able to enable MQTT client (in zipabox) by posting the json below through https://my.zipato.com/zipato-web/api.

{
"className": "com.zipato.network.mqtt.MqttNetwork",
"name": "zipato-mqtt",
"broker": "tcp://10.0.0.93:1883",
"qos": 2,
"clientId": null
}

This creates a network named zipato-mqtt successfully. However, when I try do the same via local web server, I get the response below from the device:

{
"success": false,
"error": "Something is broken"
}

Has anyone have any idea about this? Is this supposed to be a bug? Or what might I be doing wrong?

Hello Everyone,

I was able to enable MQTT client (in zipabox) by posting the json below through https://my.zipato.com/zipato-web/api.

{
"className": "com.zipato.network.mqtt.MqttNetwork",
"name": "zipato-mqtt",
"broker": "tcp://10.0.0.93:1883",
"qos": 2,
"clientId": null
}

This creates a network named zipato-mqtt successfully. However, when I try do the same via local web server, I get the response below from the device:

{
"success": false,
"error": "Something is broken"
}

Has anyone have any idea about this? Is this supposed to be a bug? Or what might I be doing wrong?

URL

2

Adrian Van Der Heijden ●

no idea. If nobody here answers, try emailing support. Please post your response here too if you dont mind.

URL

1

Peter Obel ●

Just a warning to everybody trying this at home:

Make sure your broker is running and you supply a correct address for it. If you do it wrong you can end up loosing complete connection to the zipabox. (Support can save you though)

URL

1

Adrian Van Der Heijden ●

Hi peter, when you have a functioning MQTT broker and setup, would you mind publishing an example and setup guide on our wiki page https://zipato.infoserv.wiki/

Personally I would love to give this a go myself if I can find the time.

URL

2

Peter Obel ●

I am a little pressed in time, however I already did a little writeup here: https://community.zipato.com/topic/how-to-integrate-smartthings-and-zipabox-through-mqtt that should be able to be modified into a proper guide. You are free to use it on the wiki.

URL

1

David Pritchard ●

OK, so you always need webserver.

URL

2

Peter Obel ●

No not quite, you always need a MQTT broker running. That is the bucket where all MQTT clients transfer their information. Bevywise MQTT broker comes with webserver that allows you to monitor the broker, but it is not necessary.

URL

2

Arski ●

@Adrian, @Peter - I've posted it on our Wiki. Peter, thank you for sharing.

https://zipato.infoserv.wiki/integration-notes/how-to-integrate-smartthings-and-zipabox-through-mqtt/

URL

1

Robin GUILLET ●

I have succeeded in setting up the MQTT protocol!

That’s nice.

I can interface my zipabox with a Rpi3 running Jeedom, and now all rules are migrated to the Rpi. My zipabox is only used as a 433+Z-Wave antenna.

However, I notice that mqtt notifications are a bit slower than http requests in rules for 3-4 seconds.

My zipabox, the MQTT broker and clients are all on the same local network, Ethernet.

URL

1

Pat@ ●

I have succeeded to setup the network MQTT and to get attribute values from Zipabox BUT I can't publish to the Zipabox!

I try to send a value to a virtual meter but without success, nothing happened on the dashboard of the box. Have you try it?

My published topic is: /ZIPABOX SERIAL/request/attributes/uuid/VALUE

URL

1

Alain ●

Same for me.

I receive updates from zipabox on CloudMQTT, and I publish datas on the same broker. But the Zipabox is not updated.

URL

1

Ruud Boon ●

Zipato only allow the RGB led's, Sirene and Relays to be controlled with MQTT. See spec.

Files:

URL

1

Sebastian Popovic ●

This document describes the MqTT connection with Zipato Internal application which is running on Zipatile. Internal application is managing only devices built in Zipatile.

Zipatile application is actually Zipato Local Server which is connected to Zipato Cloud Server. Both of them are accessible through another MqTT which is more or less supporting all products connected to Zipato.

This is the document describing Zipato MqTT communication:

Files:

URL

1

Ruud Boon ●

AH cool, so this is a MQTT wrapper around the http api. Pretty handy although I'm still hoping that the MQTT client that now is in place will be extended :D

URL

1

Pat@ ●

It's OK for me now.

I publish with this topic only: request/attributes/uuid/value and the message for example {"value":55}

URL

1

Alain ●

thank you Pat@. It is ok without the first "/"

URL

1

Pat@ ●

yes

URL

1

Pat@ ●

@Sebastian

your document is applicable for Zipatile and Zipabox?

URL

1

Pat@ ●

Hi

I try to modify the tcp address of my broker in the mqtt zipabox config but without success.

First I caught the UUID of the network with GET /networks

and then I made a PUT /networks/{uuid}/config with the following body :

{

"broker": "tcp://192.168.1.92:1883"

}

The return code is OK (200). I did a synch on dashboard (I don't know if it's necessary) but when I check with the GET /networks/{uuid}/config, nothing has changed.

Any idea?

URL

2

Pat@ ●

I try to delete the network but it doesn't work too => response code 204 and the network is still here

URL

1

Tom Säll ●

Hi, i hope someone can help me with the following.

I have created a virtual switch which i want to control using mqtt.

If i subscribe to its topic i receive the change of states (true/false) so its working as it should.

but when i try to publish to the device nothing happens.

im using bevywise mqttroute as broker and i can see that the broker sends the message to the zipabox in the webui.

according to mqttroute my zipabox is subscribing to /boxserial/request/#

i have tried the following syntax.

/boxserial/request/attributes/uuid/textValue -> true

/boxserial/request/attributes/uuid/value-> {"value":true}

request/attributes/uuid/value-> {"value":true}

request/attributes/uuid/textValue -> true

also tried to replace true and false with 1 and 0

im using mqtt.fx when im subscribing and try to publish. i can publish to all my other topics except the for the zipabox.

URL

1

Tomasz ●

I use node-red to send MQTT to Zipato and it works like this:

msg.topic = "request/attributes/"+msg.payload.attributeId+"/value";

and the payload MUST contain only "value" attribute. So third line you've tried actually works in my case. Double check if you haven't missed something. But if your connection in fine, and attribute type is boolean, then it works. Maybe you want to set a number attribute (like Meter attribute), then value must be a number.

EDIT: As I can see, Bevywise can show subscribed topics for connected clients, so you can verify what topics Zipato subscribes to.

URL

1

Pat@ ●

yes your third line should be ok.

See my post before: "I publish with this topic only: request/attributes/uuid/value and the message for example {"value":55}"

And be careful to choose the correct uuid of the virtual switch, it's the lowest in the hierarchy.

URL

1

Jean-baptiste M ●

Hi,

I have the same issue, for example when i use cloudMQTT. On change status of virtual, i see on the console:

/zipato/attributes/XXXXX/value{"value":true,"timestamp":"2018-02-26T13:06:34Z"}

But if i tried to publish with this syntax:

request/attributes/0ded8ce4-XXXX2b5b473f/Valuetrue (or json ssyntax)

Nothing appened......

I do not help but it shows that there is little concern

Best Regards

URL

1

Pat@ ●

you should only publish with the complete topic request/attributes/0ded8ce4-XXXX2b5b473f/value (I.e with the term value) plus the content of the message which is for example {"value":true}

URL

1

Jean-baptiste M ●

hi

Thanks for you answer, i use exactly the same syntax

request/attributes/0ded8ce4-XXXX2b5b473f/value and this message

{"value":true}

Nothing appened......

URL

1

Jean-baptiste M ●

if you have a idea, the publish value with node-red

26/02/2018 à 22:33:14node: b9e9ea2d.e2b2b8

request/attributes/0ded8ce4-fa2f-4b9f-bc06-XXX/value : msg.payload : string[15]"

{"value":false}"

Thx

URL

1

Pat@ ●

did you taken the lowest uuid in the hierarchy of the virtual device (for example uuid of the "STATE" attribute of a virtual switch)?

URL

1

Jean-baptiste M ●

hi

Yes i publish to lowest uuid. If i make change on my.zipato, i see the change on the Node red, i can read the good topic.

If i publish no affect to the Zipato.

Very strange

URL

2

Pat@ ●

did you just try with 4 nodes in node-red? For example:

1st node: Inject (Node properties: Inject once at start)

2nd node: Function (Function: msg.payload = "{\"value\":true}"; return msg;)

3rd node: MQTT output (Server = IP of your broker, topic = request/attributes/0ded8ce4-fa2f-4b9f-bc06-XXX/value)

4th node connected to the output of the 2nd node: a debug node

URL

1

Alain ●

I have the same problem. I run some python scripts to publish to zipabox which has not been modified since they were working.

I tried with CloudMqtt and local broker (Mosquitto)

URL

1

Jean-baptiste M ●

hi,

I take a capture the first item is the output of the function and the second on the node MQTT output

No affecte to the zipabox

Files:

URL

1

Pat@ ●

Humm curious... did you try to use an external tool like MQTT.fx to catch the real topic wich is sent to the network?

I have installed this tool to help me to debug the exchange between mosquitto, Zipabox, node-red and others MQTT system. With MQTT.fx you can connected to your broker and subscribe to the topic request/attributes/0ded8ce4-fa2f-4b9f-bc06-XXX/value and analyse what is really send by node-red.

URL

1

Jean-baptiste M ●

I just verify with mqtt.fx.

I publish the good value on good topic

It just doesn’t work. May be a bug on my zipabox version. I use 1.3.13 and you ?

Thanks.

URL

2

Tomasz ●

I use 1.2.29 - I never upgrade box software when suggested. It's a banana software - it ripens while shipped to the customer :) There were already two "minor" updates of current "major" update. I've missed so many problems and frustrations.

My advice is to roll back to 1.2.29 and in no circumstances upgrade box software when suggested. Wait 2-3 months when it's ripe and doesn't make your head hurt.

URL

1

David Pritchard ●

Very wise. Wait for the fix of the fix.

URL

1

Jean-baptiste M ●

i downgrade the solution, doesn't work.......

Very wise. Wait for the fix or change the box.....

URL

1

Alain ●

unfortunately the oldest installable firmware is 1.2.41

A Zipato answer wuld be nice !

URL

1

Pat@ ●

Version 1.2.29 for me.

URL

1

Alain ●

what is the firmware ID of this version ?

URL

1

Jean-baptiste M ●

Hi all,

Finaly i find the error. I have change the clientID in the configuration

So the the Topic Subscribed arn't request/attribute/xxxx but like that /zipato/request/attri

Because i use clientID: zipato

Thanks for you help

URL

1

Fredrik Winkvist ●

Have you filled in topicBase and topicPrefix too?

I have the same problem that you had but your solution is not working for me.

I have these properties set up:

"topicBase": "zipato/"

"topicPrefix": "zipabox/"

"clientId": "zipato"

It outputs as zipato/zipabox/attributes/[GUID]/value in the log.

Before the FW upgrade I could update by calling request/attributes/[GUID]/value, and if I understand your solution you suggest to put in client id as in /zipato/request/attributes/[GUID]/value.

Unfortunately it's not working for me and I think I've tried all variations such as

request/attributes/...

/request/attributes/...

zipato/request/attributes/...

/zipato/request/attributes/...

zipabox/zipato/request/attributes/...

/zipabox/zipato/request/attributes/...

URL

1

Jean-baptiste M ●

Hi,

I downgrade my firmware and it's working now. If i pass to the version 1.3.13, doesn't work.

May be a bug.

So i stay in the previously version 1.2

Bests regards

URL

1

Fredrik Winkvist ●

As addition to my previous comment, the mosquitto log shows in my case

Received SUBSCRIBE from [BOXSERIAL]

zipato/zipabox/request/#

So I guess it should work with:

zipato/zipabox/request/attributes/[GUID]/value

But it's not so I will open a ticket.

URL

1

Alain ●

Hi,

same for me. I opened a ticket.

A,

URL

1

Jean-baptiste M ●

me too

Jibe

URL

1

Tomasz ●

Are there good news about MQTT? I had to upgrade zipabox from 1.2.29 to 1.3.13 because it started to reset itself like once per hour and sometimes even twice per hour. After upgrade the problem of frequent resetting is gone, but zipabox stopped to react to incoming MQTT messages :(

It's so dissapointing :( Anyway any help appreciated - is there a way to stay with newest firmware and be able to control zipabox via MQTT?

URL

1

Alain ●

unfortunately it doesn't works on my side either.

and sadly I don't have responses to my ticket.

URL

1

Tomasz ●

Is it possible to downgrade firmware to particular version? When I select [Previous] it gets me 1.2.41 where MQTT is broken too. I need to get back to 1.2.29 but there is no option in UI. Is there a hack or workaround?

URL

2

Tomasz ●

Ok, good news is that Zipato Support can roll back your firmware to 1.2.29 and they do it fast (thank you Stefan!). In that version MQTT is working smoothly.

URL

MQTT support

Replies (43)