Good morning
âalexa â matter bridge > IHOSTâ problem
I configure Alexa by going from âMatter bridgeâ and Alexa sees all the devices not with the description entered in IHOST but as âfirst socketâ âsecond socketâ âthird socketâ and so on.
So I have to rename all the devices in Alexa so that they are identifiable for example: âfirst socketâ in Living Room.
The problem is when IHOST is turned off or the electricity goes out and in Alexa it randomly recharges all the devices by putting âsecond socketâ in the living room for example.
I have to waste 20 minutes every time to update everything, this mode is absurd.
Iâm also having problem with Sonoff MINIR4M after the update.
It appears as unavailable in ihost but works perfectly in ewelink app.
I deleted the device from ihost and realized that it does not show up in ewelink addon.
I tried to logoff/login, reboot, but nothing seems to make the device show up again.
I reproduced the situations you have described. The name change in Alexa did not happen. All the names I gave were retained. I guess you are unlucky or I am lucky
I also noticed that the names of mapped devices connected to iHost as Matter hub are not mapped. I wrote about this earlier. Perhaps the assigned names are not being passed through iHost. I think the CUBE team will look into this soon. Perhaps the problem is on the Alexa side. Anyway, this feature is currently in its experimental phase and letâs focus on the overall functionality. And itâs pretty good, isnât it? As the developers mention in the notes, âthe available features/functions of the devices depend on the Matter-supported platforms and the adaptation progress of the Matter protocol from CSAâ.
This is debatable. They arenât an option for the dashboards. they have limited functionality in scenes and in Node Red there are zero output options and the only available triggers are temperature, manual/auto/off setting, battery and RSSI. Given thereâs no way to see or change then remotely on anything less than a big screen I wouldnât have said they were supported. The lacking scenes and Node Red support could be added later but there being no way to control them without a computer is definitely wrong.
Also what on earth are channel one and channel 2 in node Red and why can I see the security status changes of my iHost in the output of the TRV?
I just received this but canât see the message on my feedback to reply to
â Now the TRVZB can support iHost, but could not support iHost cast, it may support it soon, please kindly wait.â
That is dishonest. Not being able to control the device when attached to an iHost using a phone or tablet is not compatible with saying it is supported. At most you could say it is partially supported as only if you log in using a specific device type is it possible to control the valves and the automatic scene or Node Red functionality is very very basic. Essentially you can connect the device but you canât see or do anything to them using most of the devices you might connect to the iHost with and you can hardly use them in scenes. There should at-least be a way of controlling the TRV that doesnât involve going downstairs, turning on the main computer, logging in and logging onto the iHost. Is the idea we walk round with a laptop in case we want to adjust our valves? Given how weak the scenes involving them are too itâs something like 35% compatibility between iHost and TRV. How could anyone recommend the TRV to iHost owners now? When it was said they were compatible at the very least I thought that meant theyâd appear on iHost Cast so there was some way of controlling them from here. I kinda assumed the Scenes and Node Red would be lacking but theyâre completely invisible to this device.
What youâve mentioned is indeed part of our development roadmap.
In this scenario, weâve prioritized releasing an update focusing on the essential functionality of TRV, enabling users to utilize its core features initially. Support for CAST and other features will be gradually integrated into subsequent updates.
Given the extensive workload involved in connecting and supporting numerous endpoints, achieving compatibility will naturally require a phased approach, thus consuming time.
Alternatively, we could opt for a comprehensive update ensuring full support and compatibility. However, this approach would extend the release timeline considerably. Striking a balance between these options is crucial.
SNZB-03 not execute the scene if the scene is on iHost and device is on Zigbee Bridge Pro or NSPanel PRO!
Update 1.12.0 corrected the problem related to changing the IF function from Any conditionin met to All condition is met :).
Due to the problem with the automatic change of the IF function, I moved a SNZB-01 and a SNZB-03 (Motion Sensor) to Zigbee Bridge Pro. Initially, I wanted to test if the 1.12.0 update corrected the problem related to the IF function, without moving the devices, but I found that if the scene is on iHost, SNZB-03 DOESNâT EXECUTE THE SCENE!
I also tried the version in which SNZB-03 is added to a NSPanel PRO and the scene is on iHost, but SNZB-03 does not execute the scene.
SNZB-03 executes the scene on iHost only if the device is added to iHost. The button, SNZB-01 works no matter where it is added.
I assume that the motion sensor should execute the scene on the iHost no matter where it is added (Zigbee Bridge Pro, NSPanel PRO or iHost).
Being able to set the target temperature with a mobile or tablet is a âcore featureâ. If youâre going to make the main web page not navigable for phones/tablets then the iHost dashboard becomes a core feature. Or you could change the iHost webpage to make it navigable on a phone/tablet.
After upgrading to version 1.12.0, a problem with scenes became apparent again. Interestingly, only scenes with motion sensors stopped working. Remedy: open (edit) the scene in question and save. That is, as with version 1.11.0.
After upgrading to 1.12.0, the flags for all scenes set for me with the parameter âany condition is metâ.
In addition to this, moving Matter support from the pilot option to the official option meant that Alexa had to be reconfigured to sort out the newly created mess. Alexa reported that a new Matter hub has been added. Hopefully, future updates wonât mess things up again. Update All Matter devices are gone in Alexa. Now adding iHost as a Matter hub to Alexa or Google Home is not possible.
BTW: Did you notice that the new firmware button (check) is gone from /#/setting?
Iâve successfully paired iHost on my wifeâs Alexa (iPhone) through her Amazon Echo Pop. This way she can control (within Alexa App) all the Zigbee Light Switches that are linked to the iHost and bridged to Alexa.
Iâd like to do the same on my personal Alexa Account, but I canât. The Matter Tab in the iHost menu does not provide me a QR code for pairing anymore. If I want to get a QR code, I need to remove the current Alexa already paired/declared in the iHost. But then my wife loses all controls over the zigbee switches.
I also tried to get a numeric code, from my wifeâs Alexa iHost paired entry (inside her Alexa App), and enter it manually while trying to add a new device within my Alexa App, but it does not work
âŠ
Would anyone have a clue on how to do this? (if itâs possible?)?
but has version 1.12.0 been released? My ihost says it is updated to the latest version but it is 1.11.1. What do I have to do?
Another question: in previous versions of CUBE the Lidlâs zigbee power strip (Livarno Home) worked perfectly, but from version 1.11.0 and 1.11.1 it is recognized as a different device and cannot be controlled.
Do you know if the problem has been resolved in this update?
