Qubino Flush 1D - av/på-brytare registreras ej

[nmfalk]

Hej,

Jag har fått en Qubino Flush 1D inmonterad så att jag kan styra mina ytterlampor via mitt z-wave-system och det fungerar rent tekniskt precis nästa som det ska. Nöjd så långt. Det är dock en sak som jag saknar, och som jag anar kan vara en brist i Qubinos rapportering till kontrollenheten.

Jag kan slå av/på både via z-wave och brytare. Men, om jag slår av eller på via brytaren så registreras detta inte till min z-wave styrenhet (en razberry).
Exempel: Min z-wave styrenhet säger att strömmen är på, vilket den var, tills jag slog av den manuellt med brytaren. Lampan lyser inte (vilket är helt korrekt då jag stängde av den), men min styrenhet tror att den gör det. Omvänt scenario gäller också så klart.

Jag har provat att slå på ända ner till debug-logging på min razberry och av/på via z-wave registreras klockrent precis som det ska. Däremot är det dödstyst i loggarna när jag använder den manuella brytaren. Först när jag slår av/på via z-wave så står strömmen korrekt angiven.

Någon som vet om detta är by design eller om något blev fel inkopplat av elektrikern? Bifogar en bild hur det hela kopplades in.

[Starglasses]

Jag har en VeraEdge kontrollenhet och har samma problem med min Qubino Flush 2 relays brytare.
Jag hoppas verkligen inte att det är "by design" utan något som kan rättas till. Har dock inte haft möjlighet att fördjupa mig i detta då jag har den på landet. Ska dock ut över dagen i helgen - kanske hinner kolla på det då.
Någon annan som fått detta att fungera?


Sent from my iPhone using Tapatalk

[andreas.ziegenfeldt]

Samma prb här med Qubino, har pratat med Vera och de ska kolla vad det är för fel.


Skickat från min iPhone med Tapatalk

[andersberg]

Hör gärna av dig hit Andreas om du får något svar från Vera, jag har samma problem med mina Qubino-dimrar och det börjar bli väldigt irriterande.

Det som är lite oroväckande är dock att jag misstänker att det ligger i Qubino-enheterna, då jag kan göra en poll och sen ser jag att "Status"-variabeln i enheten rapporteras som "1" fastän jag vet (och kan se i strömförbrukningen) att den är avstängd. Kanske funkar inte "Poll" från Veran iofs, men det känns ju också lite konstigt.

Är det kanske någon som kör Qubino Dimmers med andra kontrollers (Fibaro?) som har märkt av att det blir fel där också?

[dargosch]

Hej,

Jag har fått en Qubino Flush 1D inmonterad så att jag kan styra mina ytterlampor via mitt z-wave-system och det fungerar rent tekniskt precis nästa som det ska. Nöjd så långt. Det är dock en sak som jag saknar, och som jag anar kan vara en brist i Qubinos rapportering till kontrollenheten.

Jag kan slå av/på både via z-wave och brytare. Men, om jag slår av eller på via brytaren så registreras detta inte till min z-wave styrenhet (en razberry).

Jag har inget Qubino-relä så detta är bara en gissning. Kolla om din kontroller verkligen lagts in i gruppen som relät skickar rapporter om på/av till.det kan gå fel ibland när man inkluderar enheten, men är enkelt ordnat.

[Starglasses]

Har nu varit ute på landet och kollat. För Qubino Flush 2 relay skapas en huvudenhet och två subenheter; en för varje brytare i Veran. Faktum är att då jag trycker på någon av de två knapparna som är kopplade till qubinon, så uppdateras huvudenheten, men inte motsvarande subenhet i Veran - vilket är ju det man skulle vilja.
I appen ser då huvudenheten tänd ut medan de två subenheterna ser släckta ut.
Jag kan leva med detta, men det känns ju inte helt färdigt. Skulle kännas bra att få till det. Några tips?


Sent from my iPhone using Tapatalk

[Starglasses]

Jag har inget Qubino-relä så detta är bara en gissning. Kolla om din kontroller verkligen lagts in i gruppen som relät skickar rapporter om på/av till.det kan gå fel ibland när man inkluderar enheten, men är enkelt ordnat.

Bra tips. Hur kollar jag detta?


Sent from my iPhone using Tapatalk

[dargosch]

Jag har inget Qubino-relä så detta är bara en gissning. Kolla om din kontroller verkligen lagts in i gruppen som relät skickar rapporter om på/av till.det kan gå fel ibland när man inkluderar enheten, men är enkelt ordnat.

Bra tips. Hur kollar jag detta?

Hmm, det verkar i manualen (se bilagan) som att i alla fall Grupp 3 eller 5 är aktuella här. Jag vet inte vilken kontrollermjukvara du använder för din Razberry, men leta i manualen efter "Associations" och se till att kontrollern är i dessa grupper. Jag är inte säker på att Lifeline (grupp 1) används för statusuppdateringar från brytaren, och gör den inte det så kommer kontrollern inte få någon signal om den inte ligger med i rätt grupp här.

[andersberg]

Jag tycker det vore konstigt om inte grupp 1 användes för statusuppdateringar, men jag är ingen Z-wave-expert.
Jag kan dock säga att för mig är det så att ibland så får jag uppdatering i Vera när jag använder knappen.
Dessutom, även efter att jag gjort en "Poll" i Vera så ser jag alltså att "Status"-variabeln är satt till "1" fastän lampan är av. När det fungerar korrekt är den satt till "0" som förväntat.

Jag får kanske höra av mig via support till Qubino, men jag har inte hört så mycket gott om deras support...

[dargosch]

Jo, lifeline brukar räcka, men jag tycker det ser om som att Qubino valt att skicka rapporterna som rör input 1 och 2 separat på annat sätt. Till grupp 3 och 5 då, för av och på. Hur allt fungerar beror väl lite på hur tillverkaren sätter upp saker. Z-wave anger ju hur och vad som kan skickas som rapporter, men enheten bestämmer när och till vilken enhet man skickar det.
Så tycker jag att standarden verkar fungera.

[Starglasses]

Tittar i manualen för min Qubino Flush 2 relays och hittar några grupper som skulle kunna vara aktuella.
Vad är "basic on/off" respektive "switch binary report" dvs skillnaden mellan grupp 2&3?
Googlar runt men hittar ingen beskrivning av dessa.

I Verans UI7 står "N/A" när jag går in på associationer på resp. endpoint. Root device kan jag däremot sätta associationer på. Låter det rätt?

Nu har jag iaf associerat grupp 2&5 (basic on/off för respektive endpoint på root device) med kontrollern (zwave[]) - tror jag. Får dock ge mig till tåls med att testa detta till nästa gång vi åker ut till landet.

Inte riktigt plug-n-play detta...


Sent from my iPhone using Tapatalk

[Starglasses]

Har haft en del konversation med Qubinos support. Det hela landande i att Veran inte stöder "multichannel association lifeline".
Har nu kontaktat Vera - återstår att se om de håller med om problembeskrivingen och om något kan göras. Fortsättning följer.


Sent from my iPhone using Tapatalk

[nmfalk]

Många bra inlägg här!
Har haft fullt upp så inte kunnat gå igenom förräns nu. Något känns ju dock lite halvknas med rapportering av brytare då vi verkar vara ett gäng som har problem och dessutom över flera olika kontrollsystem. Ska göra ytterligare djupdykningar i min razberry och se om jag kan hitta något mer.

[Starglasses]

Fick följande svar från Vera

"Basically, if we create a scene in which whenever one of the child devices is turned on or off to poll the master device after 5 seconds.
If you want, this can be done from the advanced editor tab in scenes.You will have to select the exact triggers as mentioned above and on the advanced editor to select the specific qubino master and select to poll."

Tyvärr fick jag inte detta att fungera. Och man bekräftar ju heller inte om Veran inte stöder "multichannel association lifeline".
Någon som får ovanstående att fungera?


Sent from my iPhone using Tapatalk

[Starglasses]

Hej,

hittade följande förklaring från Qubino i ett Domoticz-forum gällande Qubino Flush 2 relay

"As you’ve noticed there is a difference between the way the S4 and S5 versions send unsolicited (Reports sent without preceding Get commands) reports to controllers. On S4 the module reports the status of the switches to the controller on every change, regardless of the way the single channel or multi channel lifeline associations were set. We implemented this in a way similar to other manufacturers, but later on had a discussion with Sigma Designs, where they explained to us the recommended way of sending unsolicited reports (they require strict separation between single channel and multi channel contexts on z-wave plus products), which we implemented in the S5 version in such a way:
- If a single channel lifeline association (group 1 associated to the controller) is set then the module shouldn’t report unsolicited Multi channel Encapsulated Reports, which means only the root device will report it’s states without a Get request, not the endpoints (these need to be polled in order to receive reports). From the module’s standpoint this means the controller either doesn’t support multi channel context or the module was integrated in a non-multi channel context.
- On the other hand, if a multi channel lifeline association (group 1 on each endpoint is associated to the controller’s endpoint 0 or 1, depending on integration) was set the module will report unsolicited reports from all the device’s endpoints, but not the root device. This will result in the endpoint’s statuses being reported via unsolicited reports also, not just Get commands via polling.

Additionally there are other association groups that can be set on the module (via single channel or multi channel associations) in order to filter the amount of report traffic desired.

Unfortunately, the controller used must also support setting multi channel associations, and additionally actually set them via an automated inclusion process after the controller’s manufacturer integrates the module (or alternatively allow users manual control of which multi channel association groups can be set).

Since you are using Domoticz (along with the OpenZwave engine) i’m afraid that the Domoticz team needs to either set these multi channel associations during inclusion, or allow users to set them manually. OpenZwave already supports multi channel associations but the Domoticz software that uses it does not.
"

fick ytterligare svar från Vera

"Hello,
I did some research on the past few days and also checked our internal tracker regarding the described issues.
I want to link this trouble ticket to the existing issue in which the problem is with the ZMNHBD1 from qubino.
As far as I see on our internal tracker the fix will be implemented in the next firmware release.
If a workaround will be discovered till then, I can let you know.
Thank you for the prompt responses and fully describing the issue.
"

Så förhoppningsvis kommer de tillrätta med detta.