cant publish with mqtt to zipabox

Hi Neil,

Can you update us on experience with Zipato 1.3.44 during last month of using it? Have you encountered any issues or everything workes fine?

Thanks in advance!

Everything works fine. This comes with a disclaimer that I no longer have all that much going on on the Zipabox, so the scope of "everything" is limited - I'd moved a lot of devices to SmartThings shortly before discovering this MQTT feature. The few devices and rules I've still got on the Zipabox have been working flawlessly on the beta firmware.

The one thing which I did need to intervene on was that once the Zipabox disconnected from the MQTT broker. It was fixed by a simple empty PUT request. I think it was probably an issue with the broker rather than the Zipabox though, and it's trivial to recover.

Hi,

Unfortunately I have observed that beta 1.3.44 can't connect to MQTT broker. Zipato Support confirmed that issue exists in latest beta and they recommend to keep version 1.2.29 until the bug is resolved. So information for MQTT users is that beta 1.3.44 doesn't work with MQTT .

It must depend on the broker. What have you tried Tomasz? I've got an installation of the Docker eclipse-mosquitto image running on my local network, and that connects just fine. It's over mqtt protocol (not websockets), uses user/pass authentication but not tls.

I used mosquitto without security (no websockets, no ssl, no user-pass) and I had no connection attempt from zipabox. Support confirmed issue and asked me to wait for update announcement. I don't know if there can be various versions of 1.3.44, but mine certainly doesn't connect to broker :)

Latest software that works with MQTT is 1.2.29, Zipabox is listening to topic request/# and you can send attribute change requests to topics in format:

request/attributes/ATTRIBUTE-GUID-HERE/value with payload {"value":true}

I can't make it work for me with firmware 1.3.61. Is it me the problem or it is the firmware version ? Please advise. I im trying to send request from Jeedom with plugin MQTT (I already receive all info of my zipabox devices without any issue). I'm trying to change http request to virtual switches with MQTT requests. Thanks.

Hi

pleae find attached the latest version of MQTT documentation. We hope it helps.

Hi,

I believe I'm doing the right thing according to the documentation.

Set attribute Request Topic: request/attributes/UUID/value

Response/Result Topic: /local/ha/bridges/zipato/attributes/UUID/attributeChangeEvents

Request Topic Payload Type: JSON Payload example: (for binary switches for example) { "value": "true" }

Description: Set attribute state with simple JSON objects

I'll will experiment more, but I was wondering if I was bound to fail with the firmaware version I'm using.

Thanks.

Hi,

I don't think 1.3.61 is a problem. Although i'm on 1.3.98 in the past i was on 1.3.61 and never encountered a problem.

For UUID: did you use the UUID of the STATE attribute of the virtual switch?

Thanks everyone. I managed to changer my virtual switch status with mosquitto_pub. So my problem is with my jeedom plugin.

@John Rabbit,

do you really managed to publish to devices on 1.3.61 ? It does not works on my side (zipabox 1, mosquitto broker), the support told me that it wont work on this fw version so I gave up using MQTT...

Thanks

Alain

@Alain

Yes I am sure. But to be more sure: this morning i rolled back to fw 1.3.61. And everything was working perfectly.

However: i am using Zipabox2. Maybe that's the reason. I don't know.

John

@Olivier,

Thanks for your observation. We now know QTT works on 1.3.61 for zipabox1 and 2 as well.

@Alain: is it possible to give a example of the topic to which you are publishing and the value? Maybe there is some error in this.

Thank you all,

This is my config:

{

"className": "com.zipato.network.mqtt.MqttNetwork",

"password": null,

"clientId": null,

"qos": 2,

"topicPrefix": null,

"name": "MQTT-zipabox",

"broker": "tcp://192.168.1.70:1883",

"uuid": "** UUID of mqtt network **",

"topicBase": null,

"username": null,

"tags": null,

"order": null

}

mosquitto_pub I tried without success:

mosquitto_pub -h localhost -t request/attributes/** UUID of STATE of virtual switch **/textValue -m true

mosquitto_pub -h localhost -t request/attributes/** UUID of STATE of virtual switch **/value -m {\"value":\"true"}

mosquitto_pub -h localhost -t request/attributes/** UUID of STATE of virtual switch **/value -m {"value":true}

mosquitto_pub -h localhost -t request/attributes/** UUID of STATE of virtual meter **/value -m {"value":10}

Hi Alain,,

I compared your config with mine. The only difference is that i have filled in clientid with "zipato" in the config.

My topics are starting with "/zipato/request/attributes/....." so starting with "/"+ clientid. Just for a wild guess: with a clientid of : "null" should your topic start with: "/"+ "request...". So an additional "/" in front? So: /request/attributes/** UUID of STATE of virtual switch **/textValue?

Good luck!

Hi Alain.This query string looks like this to me

/ZT782AC4 ********/request/attributes/******* - 0a1c-4e5f-9e4c - ******/textValue

The value to send is "0 or 1"

Hi Dima,

@Alain. Dima you're right. if the clientid is null, the box serial number is inserted.

Look at this code;

1. String effectiveClientId = clientId != null ? clientId : ZipatoHelper.getSerial();
2. String base = topicBase;
3. if (base == null) {
4. base = "/";
5. }
6. String prefix = topicPrefix;
7. if (prefix == null) {
8. prefix = effectiveClientId + '/';
9. }
10. root = base + prefix;

So Dima you're topic is /serialnumber/request/attr.... and that's exactly what Alain should use. Or he must change the clientid in the config in a value <> null.

Cheers,

John

I agree with you John.

"Or he must change the clientid in the config in a value <> null."

Thank you for your advises.

I think that I have try every combinaison possibles with or without clientId, all with no luck....

with "clientId": "client" :

client/request/attributes/91****39f/textValue -m "1"

/client/request/attributes/91****39f/textValue -m "1"

/0*serial*3/request/attributes/91***39f/textValue -m "1"

0***3/request/attributes/91***39f/textValue -m "1"

/request/attributes/91***39f/textValue -m "1"

request/attributes/91***39f/textValue -m "1"

and with "clientId": null

/0***3/request/attributes/91***39f/textValue -m "1"

0***3/request/attributes/91***39f/textValue -m "1"

/request/attributes/91***39f/textValue -m "1"

request/attributes/91***39f/textValue -m "1"

Note in the documentation there is a response topic:

Request Topic: request/attributes/UUID/textValue

Response/Result Topic: /local/ha/bridges/zipato/attributes/UUID/attributeChangeEvents

I have never seen any message on this /local/ha topic

@Alain,

Can you add the -d option to the request: so:

/client/request/attributes/91****39f/textValue -m "1" -d

Maybe this debug option can give some additional info.

well, I did a reboot of the box and now it is working with this format :

/serial/request/attributes/UUID/textValue

Thank you so much John, Dima and Olivier for your help

Alain

For me it's working with mosquitto_pub -t "zipatozipabox/request/attributes/UUID/value" -m '{"value":true}'

my config is

"clientId": null,

"qos": 2,

"topicPrefix": "zipabox",

"name": "MQTT",

"topicBase": "zipato"

Yes, thank you Olivier, that is working for me too.

I should advise support that MQTT is ok !!

Given all your positive messages, I would like to try and have another go at getting MQTT to work oin my Zipabox v1. I first tried to do it using the API:

using POST/networks I created a network with this config:

{

"className": "com.zipato.network.mqtt.MqttNetwork",

"password": "REDACTED",

"clientId": "null",

"qos": 2,

"topicPrefix": "zipabox",

"name": "MQTT",

"broker": "mqtt://192.168.0.220:1883",

"uuid": "3641e886-0b27-4d0e-bdbf-b4a129a82828",

"topicBase": "zipato",

"username": "mqtt",

"tags": null,

"order": null

}

However the MQTT server did not start receiving messages.

What did work is to not use the API but to add a MQTT.org device in the Zipato UI. I started receiving messages from the Zipabox.

However then my MQTT server changed IP and things stopped working. I gave my MQTT server a fixed IP and updated the IP using the API. That didn't work (well the IP shows that the IP has updated, but no messages appear on the MQTT server).

I want to somehow remove MQTT from the UI so that I can add it again, but don't see any functionality to do that. I tried to remove it using the API (DELETE/networks) but that doesn't work. Even if I delete the network using the API, when I use GET/networks, the MQTT network still shows up in the list... It obviously also shows up in the UI.

Does anybody have any suggestion of what I could try to get it to work?

Hi quizzical.

After each change of settings (via api too) you need to synchronize the device.

Hope this helps. Be careful ;-)

Oh man I love you! It works now :-D

Thank you so much!

Now comes the more difficult step for a complete novice like me:

How to get Home Assistant to read these mqtt messages and understand them, and then also be able to push messages to the Zipabox.

Seems like someone has recently tried this, but it reads like chinese to me

Very easy.

Install MQTT

For a switch (receive status and set value):

- platform: mqtt

name: 'room 1'

state_topic: "/**zipabox ID **/attributes/** switch UUID**/value"

command_topic: "/**zipabox ID **/request/attributes/** switch UUID**/value"

value_template: "{{ value_json.value }}"

payload_on: '{"value":true}'

payload_off: '{"value":false}'

state_on: true

state_off: false

Sensor:

- platform: mqtt

name: "Temp Freezer"

state_topic: "/**zipabox ID **/attributes/** sensor UUID**/value"

unit_of_measurement: '°'

value_template: "{{ value_json.value }}"

hope that help.

A.

Hurray! with your great example codes I integrated a switch in Home Assistant! Feels like magic to a novice like me :) Thank you very much!

Do you know how to integrate devices that are not a simple switch or a sensor? For example from my zipabox I can control my ventilation system (0% to 100% ventilation speed), or some lights (0-100%), I have multisensor devices (so not only temperature like in your example, but also humidity and luminance), I have HTTP virtual devices like Virtual Meters in which I store many variables,...

I understand there is an auto discovery feature in Home Assistant to automagically discover MQTT devices, I assume that doesn't work for the Zipabox devices?

In addition to the topic 'attributes' there is also a topic 'devices' were the Zipabox publishes information, are there scenario's in which this can be usefull in Home Assistant? The number of messages there seems to be much more limited than under 'attributes'.

What I find very strange, is that if I look in the Zipato API for the UUID of a particular device, I can only find that UUID in the 'devices' topic. The only way I have managed to find the UUID I need to use for the 'attributes' topic is to trigger the device in question many times and see for which UUID new messages are being posted.

I'm very excited to finally be able to seriously start working with Home Assistant. So far I was able to do some interactions with HTTP Requests between Home Assistant and the Zipabox but that was very cumbersome!

Hi,

I dont have a ventilation but this is a cover which I can set from 0 to 100%:

cover:

- platform: mqtt

unique_id: "store"

name: "store"

retain: false

position_topic: "/**zipato ID**/attributes/**UUID**/value"

set_position_topic: "/**zipato ID**/request/attributes/**UUID**/textValue"

value_template: "{{ value_json.value }}"

position_open: 100

position_closed: 0

I have never managed to use the autodiscovery. To find the UUID the best I find is to use the device manager (not device browser), unfold the hierarchy to STATE or the telemetry you want.

If a device has several attributes you must set one configuration per attribute.

Thank you Alain,

As a test I used your code to integrate a dimmable light and tried two other methods, none of them work properly.

In the zipabox the light is represented as a slider which I can move from the left (0) to the right (100).

MQTT message sent by the dimmable ligt;

{"value":0,"timestamp":"2020-11-14T08:00:41Z"}

{"value":100,"timestamp":"2020-11-14T08:00:41Z"}

And off course any value in between 0 and 100.

To adjust the light a message like this needs to be sent:

{ "value": 0 }

Where 0 turns off the light and 1-100 set a specific brightness level.

Now my attempts to try and integrate it:

Method 1 using the code you shared:

cover:
  - platform: mqtt
    name: "Test3"
    position_topic: "/Zipabox/attributes/5aceaf68-7430-445a-90cb-a7166e17c315/value"
    set_position_topic: "/Zipabox/request/attributes/5aceaf68-7430-445a-90cb-a7166e17c315/value"
    value_template: "{{ value_json.value }}"
    position_open: 100
    position_closed: 0

17

Where the light expects { "value": 17 }

Another issue is obviously that Home Assistant thinks it's a cover and not a light.

Method 2 which correctly identifies it as a light, and can sort of read the correct brightness but not set the brightness.

light:
- platform: mqtt
name: "Test 1"
brightness_state_topic: "/Zipabox/attributes/5aceaf68-7430-445a-90cb-a7166e17c315/value"
command_topic: "/Zipabox/request/attributes/5aceaf68-7430-445a-90cb-a7166e17c315/value"
brightness_command_topic: "/Zipabox/request/attributes/5aceaf68-7430-445a-90cb-a7166e17c315/value"
brightness_scale: 100
brightness_value_template: "{{ value_json.value }}"
on_command_type: 'brightness' #Using brightness will only send brightness commands instead of the payload_on to turn the light on.

HA doesn't read the values sent by the light when HA thinks the light is off. When it thinks the light is on it (because I clicked the light in HA) it does read the values, so if HA reads 100 the slider goes to the right and the animated bulb shows maximum brightness. If it reads 50 the slider goes to the middle and the bulb is less bright. If it reads zero the slider goes to the left and curiously enough the bulb shows maximum brightness.

Method 3, which can correctly set the brightness, but not read the brightness level

light:
- platform: mqtt
name: 'Test 2' 
schema: template
command_topic: "/Zipabox/request/attributes/5aceaf68-7430-445a-90cb-a7166e17c315/value"
state_topic: "/Zipabox/attributes/5aceaf68-7430-445a-90cb-a7166e17c315/value"
state_template: '{{ value_json.value }}'
command_on_template: '{ {% if brightness is defined %}"value": {{ (brightness / 2.55)|int }} {% else %} "value": "15" {% endif %}}'
command_off_template: '{"value": "0"}' 

When clicking the light switch in HA:

* the light turns on with brightness level 15 so physical behaviour is correct

* however in lovelace the brightness slider does not move

* in addition in lovelace the light switch button (which I just turned on) switches back to off after one second (in reality the lgiht remain on a level 15).

If I turn off the light in HA, the light turns off.

If I change brightness levels outside of HA, HA does not read this.

The little animated lightbulb never does anything (whether I manipulate the light physically or in Home Assistant).

So with many hours of effort (because I don't really understand properly the code I have created), I still haven't found a method to do something extremely simple:

integrate a light which only sends brightness values (no on or off) using the format {"value":17,"timestamp":"2020-11-14T08:00:41Z"} and which can only receive brightness values (no on or off) using the format { "value": 0 }

Hi,

you must define the state (for the switch button status) and brightness (for the slider) value to have a feedback of the state

- platform: mqtt

schema: template

command_topic: "//request/attributes//value"

state_topic: "//attributes//value"

command_on_template: >

{{%- if brightness is defined -%}

"value": {{ brightness | float | multiply(0.3922) | round(0) }}

{% else %}

"value": 100

{%- endif -%}}

command_off_template: '{"value": 0}'

state_template: '{% if value_json.value > 0 %}on{% else %}off{% endif %}'

brightness_template: '{{ value_json.value }}'

Alain,

Thank you very much for your expertise!

With some minor tweaks (adjusting the brigthness template to multiply the incoming value by 2.55) it now works perfectly! Had a strange issue that the Zipabox stopped sending MQTT values for this light (other things still worked), but was solved by a reboot of the Zipabox.

Here is the final code:

  - platform: mqtt
    name: 'nameofyourdevice'
    schema: template
    command_topic: "/xxx/request/attributes/xxx/value"
    state_topic: "/xxx/attributes/xxx/value"
    command_on_template: >
      {
      {%- if brightness is defined -%}
      "value": {{ brightness | float | multiply(0.3922) | round(0) }}
      {% else %}
      "value": 100
      {%- endif -%}
      }
    command_off_template: '{"value": 0}'
    state_template: '{% if value_json.value > 0 %}on{% else %}off{% endif %}'
    brightness_template: '{{ (value_json.value * 2.55) | int  }}'

binary_sensor:
  - platform: mqtt
    name: 'PIRSensor Garage'
    state_topic: "/xxx/attributes/xxx/value"
    device_class: motion
    value_template: "{{ value_json.value }}"
    payload_on: '1.0'
    payload_off: '0.0'

Thanks again Alain!

OK I succeeded in making the smart garage door. In case anyone is interested you can find it at the bottom of this post.

Unfortunately every time i restart Home Assistant, it forgets the status of the garage door. Do you have a solution to Home Assistant remembering the state of lights/doors/... when home assistant reboots? I guess it's the same problem as is mentioned here.

PS: My Home Assistant regularly gives me this error:

Login attempt or request with invalid authentication from 192.168.0.164 (192.168.0.164) (okhttp/3.7.0-SNAPSHOT),

Creating a smart garage door in Home Assistant from Zipox garage door switch and sensor

The configuration below:

1: creates a switch that triggers the Z-wave device controlling my garagedoor (when this device is turned on, it will trigger the engine of the garagedoor (which will open, close or stop depending on what position it was in or whether it was allready running, and turn itself off after 1 second).

2: creates a sensor that reads the z-wave door sensor that I have mounted on my garage door to detect whether it is open or closed

3: creates a combined device that can read the position of the garage door, allow you to open/close the garage door (the open button is for example greyed out when the door is allready open), and show an icon that displays the open/closed state of the garage door.

switch:
  - platform: mqtt
    name: 'Switch Garagepoort zonder sensor'
    state_topic: "/xxx/attributes/xxx/value"
    command_topic: "/xxx/request/attributes/xxx/value"
    value_template: "{{ value_json.value }}"
    payload_on: '{"value":true}'
    payload_off: '{"value":false}'
    state_on: true
    state_off: false

binary_sensor:
  - platform: mqtt
    name: 'Sensor Garagepoort'
    state_topic: "/xxx/attributes/xxx/value"
    device_class: garage_door
    value_template: "{{ value_json.value }}"
    payload_on: true
    payload_off: false

cover:
  - platform: template
    covers:
      garage_door:
        device_class: garage
        friendly_name: "Garagepoort"
        value_template: >-
          {% if is_state('binary_sensor.sensor_garagepoort', 'on') %}
            open
          {% else %}
            closed
          {% endif %}
        open_cover:
          service: switch.turn_on
          data:
            entity_id: switch.switch_garagepoort_zonder_sensor
        close_cover:
          service: switch.turn_on
          data:
            entity_id: switch.switch_garagepoort_zonder_sensor
        stop_cover:
          service: switch.turn_on
          data:
            entity_id: switch.switch_garagepoort_zonder_sensor
        icon_template: >-
          {% if is_state('binary_sensor.sensor_garagepoort', 'on') %}
            mdi:garage-open
          {% else %}
            mdi:garage
          {% endif %}

And here is the code for integrating a light that you can just turn on or off (not brightness control etc):

light:
  - platform: mqtt
    schema: template
    name: "chooseanameforyourlight"
    state_topic: "/xxx/attributes/xxx/value"
    command_topic: "/xxx/request/attributes/xxx/value"
    command_on_template: '{"value":true}'
    command_off_template: '{"value":false}'
    state_template: '{% if value_json.value == true %}on{% else %}off{% endif %}'

OK I have another update to share, which I believe is really usefull. The Zipabox doesn't include the retain flag in its MQTT messages. As a result when you reboot Home Assistant, it looses all knowledge of the state of the devices connected to your zipabox (whether a light/switch/door,... on/off/open/closed).

The solution I found with some help is to create an automation in home assistant which forwards the messages coming from the Zipabox do another topic, but adds the retain flag. The integrations in Home Assistant (the examples mentioned in my previous posts) then need to point to this new topic to receive the states.

Here is the code for the automation:

  action:
    service: mqtt.publish
    data:
      topic: "/z2hasd/{{ trigger.topic.split('/')[3] }}/value"
      payload: "{{ trigger.payload }}" 
      qos: 2
      retain: true
  mode: parallel #Allows MQTT to process multiple processes simultaneously
  max: 50 #The default of 10 concurrent processes is not enough in my case, so I put it to 50.

quizzical, great job!

last week, i started building HA, and now i came to zipabox integration and your posts helped me to create entities. I set up mqtt on HA and on zipabox. I'm able to receive messages from zipabox, but when I send a message to zipabox, nothing happens.

command are:

    state_topic: "/zipato/attributes/154b9ccf-6ba4-4946-bfbf-72a488be165a/value"
    command_topic: "/zipato/request/attributes/154b9ccf-6ba4-4946-bfbf-72a488be165a/value"

i was able to turn on max logging on mqtt broker, and in log i see this subscription:

2020-11-17T08:13:21: Received SUBSCRIBE from zipato

2020-11-17T08:13:21: /zipato/request/# (QoS 0)

2020-11-17T08:13:21: zipato 0 /zipato/request/#

I also see, that messages are sent to zipabox:

2020-11-17T08:13:21: Sending PUBLISH to zipato (d0, q0, r1, m0, '/zipato/request/attributes/154b9ccf-6ba4-4946-bfbf-72a488be165a/value', ... (4 bytes))

but, nothings happens :( i also tried almost all combination within topic.

can you help please?

i'm on FW 1.3.13

Hi Martin,

I don't use mqtt.fx so can't comment on your logs.

Have you tried as a test to use mqtt.fx to publish a message publish a message like '{"value":true}' in topic "/zipato/request/attributes/154b9ccf-6ba4-4946-bfbf-72a488be165a/value"?

Off-course you need to adjust 'true' to the values your device expects. If your device reacts then we know that part works. If not the problem is in your zipabox, or you've used the wrong message or topic.

If it works: try to trigger the device in Home Assistant and look with mqtt.fx in topic "/zipato/request/attributes/154b9ccf-6ba4-4946-bfbf-72a488be165a/value". Did Home Assistant publish a message there? Does it have the right format?

Checking all these things should help you isolate where the problem is and find the solution.

OK I discovered 2 problems (one major and one minor) and further improved the automation to add a retain flag:

My zipabox seems to sometimes only pass some of the messages. E.g. if over the timespan of a minute I change the brightness of a lamp 10 times, it might only send the MQTT message 3 of the times. The fix is easy: after I reboot my Zipabox all is good. But that is clearly not a permanent fix. Do any of you face this issue and how did you solve it?

The best solution I can think of is to plug my zipabox into a smart switch and have that smart switch turn off and then on somewhere during the night, but that can't be very good for the Zipabox...

Second problem is that when I reboot Home Assistant, the automation to forward the messages to a new topic with the added retain flag does not work. So those messages never arrive in the new folder and will therefore never be read by my integrations in home assistant. I guess I can live with that.

I discovered that the Zipabox published the battery level of my smoke sensors in the devices topic so I have made my code to add the retain flag to MQTT messages more generic so that it also captures and republishes those messages.

Here's the code:

- alias: 'Add retain flag to Zipato MQTT messages' #This automation reads all Zipabox MQTT Messages and forwards them to another topic (used by the HA Integrations) but with the added retain flag. This way when HA reboots, it remembers the state of my devices.
  trigger:
    platform: mqtt
    topic: /Zipabox/+/+/+
  action:
    service: mqtt.publish
    data:
      topic: "/z2ha/{{ trigger.topic.split('/')[2] }}/{{ trigger.topic.split('/')[3] }}/{{ trigger.topic.split('/')[4] }}"
      payload: "{{ trigger.payload }}" 
      qos: 2
      retain: true
  mode: parallel #To be able to process multiple payloads simultaneously
  max: 50 #To increase the max number parallel processes from 10 (which still resulted in skipped messages) to 50

quizzical, "My zipabox seems to sometimes only pass some of the messages". i see same behaviour and no direct solution for it. For example, I see 2-3 times a day, that some door is open, even when it is closed.

I ordered a z-wave.me usb for mi RPI4 and will migrate easy accessible devices. i was able to migrate almost all rules except for heating, this must work these days.

I'm also considering to order a z-wave USB stick.

why did you choose the z-wave.me? I was thinking of choosing the aeotec, because I really don't want to unmount the in-wall z-wave devices and the aeotec usb stick has a built-in battery allowing you to take the usb-stick to the z-wave device and do the inclusion there.

As a downside I heard the aeotec can't be updated while the other ones like z-wave.me can.

I heard that it should be possible to somehow add the usb-stick as a slave to zipato network first and then have it take over the z-wave devices, this way you don't have to manually remove all the devices from the zipato network and then join them to the new usb-stick. In addition I think you can have both the zipato and the new usb stick control the devices untill you are ready to abandon the zipabox. Have you tried that?

Which z-wave solution did you choose for Home Assistant? Zwave2mqt or the built-in solution? And on what basis did you make the decision?

i ordered yesterday and it will arrive next week. i have taken z-wave.me because aeotec doesn't work with RPI4. for the inclusion, i will use a power bank for RPI and bring it closer :)

z-wave solution: i will have to read during weekend about it a then play around amd test it with few devices

@quizzical: I'm interested in learning more about slave trick for the z-wave usb key. I'm now using jeedom on a RPI3 as my main controler and zipabox only as a gateway for zwave devices replicated in jeedom with mqtt. I also have bought a zwave.me usb key but nothing paired on it yet.

@Olivier, lucky for you I did a search an managed to find back the post I had read a long time ago.

https://community.openhab.org/t/gradual-migration-from-zipabox-primary-and-secondary-controllers-etc/77525/23

Please report back if you succeed and how you did it :)

@Olivier, I ordered the new Z-stick gen5+ so I will give it a try soon as well. Did you have any luck?