Status updates for Qubino Relays/Dimmers generally do not work

Daniel_Linder · January 8, 2018, 7:00pm

Ok, interesting.
If you ever get them up and running - I would be most thankful for a some feedback.
I have a few just acting “dust collectors”. I am sure I could find some use for them eventually…

vossivossi · January 8, 2018, 8:23pm

I think without these “pending database updates” it will NOT generally work at the moment as our tests here have clearly shown. The current dev version (201801021718) will ONLY work if you have activated additional endpoints in the configuration (which is not the default configuration of the device).
So please @chris could you integrate these “pending database updates” soon? Thanks!

smar · January 9, 2018, 10:59am

I contacted Qubino recently, and they said that if I wanted a firmware upgrade, to return the relays to the supplier I bought them from, and they would organise with Qubino for an upgrade. This may be worth doing if Chris isn’t able to find a work around for these older 1.1 firmware units.

shorty707 · January 9, 2018, 4:27pm

For the DIN DIMMER ZMNHSD Qubino says the current version is:
H1S2P2
( A newer version H1S3P2 is on the way but not yet released)

Just if somebody wonders what the current version is

mdnx · January 10, 2018, 11:00pm

Today I exchanged my Qubino Flush Dimmer (with newest firmware) with a Fibaro Dimmer 2 - what a relief.
Plug and Play - it works on first try with several parallel moment switches, is immediately found and integrated into the Zwave network, the device (as all other Fibaro devices I have) reports automatically - everything works just out of the box.

I don’t now why I obtained a Qubino, when all my Fibaro devices work brilliantly and I was actually aware of this threat - However For anyone considering buying a Z-wave Dimmer or relay: - so far 292 entries on a basic functionality of any Z-wave device should be a warning in itself

vossivossi · January 10, 2018, 11:27pm

Well, careful! The electric properties of the Qubino Flush Dimmer are more than excellent! Dimming even a load of just 4W LED is no problem at all, while the Fibaro (from my tests 1,5 years ago) was never working reliable for its MAIN PURPOSE which is dimming anf switching a light. And dimming loads < 50W is only possible with the extra installation of a bypass (which the Qubino does not need). So there are already very good reasons to consider the Qubino.
AND: the ONLY problem with the Qubino Flush Dimmer is the use of aditional endpoints. The normal operation for 1 load works without any problems and this is probably the most frequently used configuration for all users. (The only unlucky exception is for dimmers which are included for the first time now with the most recent dev binding 20180102, which in contrary will only make dimmers work with activated additional endpoints; I already shouted to @chris to bring back the normal switch_dimmer channel, but so far no updates)

chris · January 10, 2018, 11:29pm

Sorry - I’ve been rather busy over the past few days and haven’t had the time. I’ll try and update this over the next couple of days unless of course someone else wants to add it before I get there…

vossivossi · January 10, 2018, 11:31pm

I would be happy to do it, but I am not sure what to do exactly.

chris · January 10, 2018, 11:36pm

Actually it looks like I already updated the database… I’ll do a binding update tomorrow if I get time, otherwise Friday.

houz · January 11, 2018, 9:40am

@chris:
Could you summarize for me what the current status is? I am using DIN rail Qubino dimmers, type ZMNHSD1 H1S2P1, firmware 1.1. I am running openHAB snapshots from the raspi packages, so no dev version. I don’t have temperature sensors attached to the dimmers.

Is there any chance to receive status updates in openHAB when dimming or switching the lights with the physical button attached? There has been so much going on here that I totally lost track.

sihui · January 11, 2018, 11:18am

Take a look at @vossivossi’s post, that should be all you need.

houz · January 11, 2018, 11:53am

I only understand half of that. What are activated additional endpoints? Isn’t that the temperature sensors you can attach? And isn’t he talking about how well the dimmer works? I was asking about how well openHAB works.

sihui · January 11, 2018, 1:50pm

You need to read the whole thread. It is all in there …

vossivossi · January 11, 2018, 10:22pm

I agreee that it is more than hard to follow this thread if you did not follow it in details or contributed to the testing. So I will try to explain:

You can activate additional reporting functions for the dimmer by changing its configuration parameters and afterwards excluding and reincluding the device to the network. The parameters 100 and 101 allow to enable/disable the endpoints I2/I3 (which would allow you for example to connect another switch or binary sensor to the dimmer device on the physical inputs I2 or I3 and report their status changes to the controller). Another option is to connect a temperature sensor which also then represents an additional endpoint.

Yes, one of the 3 options to acitivate additional endpoints as stated above. (I2, I3, temperature sensor)

Correct, the dimmer performs its main original task (=dimming light) excellent, even with very low LED loads

This depends indeed from several criteria: The Z-Wave-Bind version you are using (or have used) to include the device and the activated (or not activated) endpoints on the device. From my experience:

Z-Wave Snapshot binding (non dev version): works fine for endpoint 0 (switch_dimmer) in any case (with or without activated additional endpoints) , but never for the additional endpoints.

Z-Wave Dev Binding before 20180102 (my latest before was 20171230): works fine for endpoint 0 (switch_dimmer) in any case (with or without activated additional endpoints) , but never for the additional endpoints.

Z-Wave Dev Binding from 20180102 (the most recent dev version): Does NOT work for switch_dimmer if NO additional endpoints are activated. BUT: Works for switch_dimmer1 and additional endpoints as soon as at least one additional endpoint is activated.

These are at least my findings.

For a solution the last suitable solution discussed here is to reactivate the channel ‘Switch_Dimmer’ (which was deleted in the 20180102 dev version). This would allow people without additional endpoints to have everything work with channel switch_dimmer. Users with additional endpoints could use switch_dimmer1 (for the light) AND the additional endpoints.

However @chris has not yet published a new dev version with this workaround solution. But he wants to do this until tommorow.

mrRobit · January 11, 2018, 10:44pm

I did the same thing yesterday. I replaced my Qubino ZMNHBD Flush 2 relay v1.2 for new Qubino Flush 2 Relay Plus (ZMNHBD1 H1S5P2) v5.0 with no cost (I only had one). It immediately started to work with the latest stable openHAB release 2.2.0-1 and z-wave binding.
I suppose replacing Qubino relays is the best solution both for endusers and for @chris if your reseller is willing to replace.

vossivossi · January 13, 2018, 11:29pm

Hi Chris, could you already find the time for the binding update?

Thanks,
Martin

Guido_van_Haasteren · January 21, 2018, 11:42am

I am not sure whether this is related, if not, tell me and I will start enother thread.
I use Openahbian on Raspi 2B, OH2.2.0-1 Releas-built, Aeon Z-stick Gen5.
I have several Qubino Flush 1 Relais, Flush 2 Relais, and a Flush shutter. Satusupdates are sometimes working sometimes not. For now I am testing a Flush 2 Relais ZMNHBD1, firmware v5.0, and for the test I deleted everything in my items-file, rules-file and sitemap, except the following parts. I did not delete any things.
I have a physical switch connectend to only to l1, which switches the light. My simple rule then switches on the ventilation with the second relais. In the end there will be more logic to this. But I have the problem that once every 3-4 times I turn on the light, the light will stay on for several seconds, then it will go out for a few seconds, end the both the light and the ventilation are turned on. Sometimes I can here switching goining on several times, without either the ventilation or the light coming on.
Underneath you find my logging. As far as I can tell, only the intended swiching is logged. (I did not yet turn on zwave debug logging, will do that after this post and report back if interesting).

items:

Group Badkamer
//Badkamer
Switch Lamp_BK "Licht badkamer" <switch> (Badkamer) { channel="zwave:device:f4f7d5ef:node13:switch_binary1"}
Switch Ven_BK "Ventilator badkamer" <switch> (Badkamer) { channel="zwave:device:f4f7d5ef:node13:switch_binary2"}

sitemaps:

sitemap default label="Sonsbeek"{
        Switch item=Lamp_BK
        Switch item=Ven_BK
}

rules:

rule "Ven_bad_aan"
when
	Item Lamp_BK changed from OFF to ON
then
	Ven_BK.sendCommand(ON)
end

rule "Ven_bad_uit"
when
	Item Lamp_BK changed from ON to OFF
then
	Ven_BK.sendCommand(OFF)
end

log:

2018-01-21 12:09:36.488 [vent.ItemStateChangedEvent] - Lamp_BK changed from OFF to ON

2018-01-21 12:09:36.496 [ome.event.ItemCommandEvent] - Item 'Ven_BK' received command ON

2018-01-21 12:09:36.529 [vent.ItemStateChangedEvent] - Ven_BK changed from OFF to ON

2018-01-21 12:09:36.545 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_ack changed from 5321 to 5322

2018-01-21 12:09:36.551 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_sof changed from 15582 to 15583

2018-01-21 12:09:36.751 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_sof changed from 15583 to 15584

2018-01-21 12:09:39.987 [vent.ItemStateChangedEvent] - network_device_192_168_0_21_time changed from 601.0 to 618.0

2018-01-21 12:09:45.708 [vent.ItemStateChangedEvent] - zwave_serial_zstick_f4f7d5ef_serial_sof changed from 15584 to 15585

2018-01-21 12:09:46.245 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_available changed from 581 to 580

2018-01-21 12:09:46.254 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_cpu_load changed from 31.4 to 31.8

2018-01-21 12:09:46.274 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_availablePercent changed from 59.9 to 59.8

2018-01-21 12:09:46.314 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_usedPercent changed from 40.1 to 40.2

2018-01-21 12:09:46.348 [vent.ItemStateChangedEvent] - systeminfo_computer_openHABianPi_memory_used changed from 389 to 390

Is this problem related to the problems of reporting state in this thread? Or should I ask for help in a new thread?
Maybe also related: my zwave mesh does not look much like a mesh…

Guido_van_Haasteren · January 22, 2018, 8:56pm

I’m afraid I have to confirm that with OH2.2.0-1, the Qubino Flush-2 relais do not report back their state.
My rules work when I change inputs to the rule from the sitemap, but not from the fysical switches connected to the Relais.

vossivossi · January 22, 2018, 9:38pm

This has nothing to do with the OH2 release as such, the important point is which version of the Z-Wave binding do you use? You can get the version in Karaf Console with the list command.

Guido_van_Haasteren · January 23, 2018, 8:59am

Oww, I though newer OH would install corresponding number Zweave-binding.
I did:
ssh into Raspberry Pi (Openhabian)
ssh -p 8101 openhab@localhost
bundle:list

And found: 222 Active 80 2.2.0 Zwave binding

I guess this means I am on Zwvae binding 2.2.0?
Should I upgrade to newest version? I believe this would be 2.3.0?

I hastitate to do this since I see so many problems in this forum about upgrading. But If I am right the instructions would be to:

Deinstall Zwave binding from PaperUI
Upgrade OH from stable to snapshot from openhabian-config
Download latest binding-jar from link in main zwave refractoring-thread
And then reboot
If no zwave-binding, type command from Karaf Console (??) feature:install openhab-transport-serial
Reboot again

Is this alright?