My V2 devices have remained online throughout all the failures and rebuilds. No custom apps.
Powered off the HE for an hour and now 17 of my 19 V1 outlets are gone too.
I power cycled a couple of them and they didn't come back.
Is it normal for staff support to not participate in this forum? Or am I not requesting help in the proper way?
In your specific situation, I would recommend you email support@hubitat.com. I would guess the Hubitat team would like to understand the Iris v1 issues you're experiencing.
2 Likes
If you are requesting support from Hubitat's support staff, send an e-mail to support@hubitat.com.
I would guess that causes a ticket to be created so your problem/issue can be tracked.
1 Like
Don't feel left out. Mine worked yesterday and saw my routes, and now today I'm in your position. I suspect this is something to do with the browser or on second thought, I'm gonna reboot my hub.
PS- i'm on the latest release 2.0.8.119.456.324.587.654.321.123.456.789.10 (JK why so many numbers!)
3 Likes
Other schemes impart meaning on individual sequences:
- major.minor[.build[.revision]] (example: 1.2.12.102)*
or - major.minor[.maintenance[.build]] (example: 1.4.3.5249)*
Again, in these examples, the definition of what constitutes a "major" as opposed to a "minor" change is entirely subjective and up to the author, as is what defines a "build", or how a "revision" differs from a "minor" change.
-- wikipedia
You knew there WAS an answer right??
(Also a joke. you know.. that there is someone pedantic enough to go search for an answer to a rhetorical question.)
2 Likes
I almost answered last night with the same answer, but decided I was being way too geeky and deleted it. LMAO
1 Like
So I removed some Osram BUlbs early and still had problems. I had forgotten about some Osram Light Strips that were plugged in. Seems I have a solid network now. IRIS must have done some special handling for the Osram stuff, but it's all the trash now. Sengleds are coming tomorrow and a Wi-Fi light strip that I am going to try to scab in somehow.
wifi lightstrip? check out the H801 (ESP8266 based) that can be flashed to run on hubitat, fairly easy to do.
Firmware done by one of our community guru's
https://smartlife.tech/blog/2016/06/24/smartlife-h801-esp8266-based-rgbw-controller/
Sorry if I missed a post explaining this, but can someone explain to me what I'm looking at via the getChildandRouteInfo page?
Like I get some of the data values, et al, but I'm not sure what each section is supposed to be:
Parent child parameters
EzspGetParentChildParametersResponse [childCount=1, parentEui64=0000000000000000, parentNodeId=65535]
Child Data
child:[Front Door Motion Sensor, 91D8, type:EMBER_SLEEPY_END_DEVICE]
Neighbor Table Entry
[Sunroom Smart Plug, 6DD1], LQI:254, age:4, inCost:1, outCost:3
[Khan's Smart Plug, CB11], LQI:121, age:7, inCost:7, outCost:0
[Christmas Tree Smart Plug, CE44], LQI:240, age:4, inCost:5, outCost:1
Route Table Entry
status:Unused
status:Active, age:64, routeRecordState:0, concentratorType:None, [Bathroom Keypad, 6331] via [Christmas Tree Smart Plug, CE44]
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
status:Unused
Assuming the Neighbor Table Entry are devices that can act as repeaters? However, this looks like only one of my devices, the "Bathroom Keypad" is routing through a parent, "Christmas Tree Smart Plug" before hitting the hub? Then what's the "Child Data" section listing "Front Door Motion Sensor" supposed to be? Also, interesting that, if the my understanding of the above is correct, the keypad wants to go through the plug instead of directly to the hub, since the plug* is further away and not in between the keypad and the hub.
That is how I interpret it as well.
Child data is a list of devices communicating directly with the hub.
2 Likes
Huh, well what's it mean when only one of your 20 odd devices is listed?
not much if all your 20 Zigbee devices are working correctly, the remaining 19 should be connecting to the hub via one of your routers.
The route table data is transient, so only active/recent routes are shown.
1 Like
Also remember that source routing is used here too, therefore the hub maintains a completely separate routing table from what is shown on that page. On my hubs, both with nearly 100 Zigbee devices each, the routing table on that report is never populated with more than 1 or 2 items.
It would be nice if @chuck.schwer could add that information to the page. 
Ok, that makes sense. Sorry for all the questions - I'm really curious when it comes to troubleshooting -
I guess the real question is, why do some of my devices decide going direct to the hub is better than going through one of the plugs (assuming only one route being shown this is what's happening)? I specifically moved some of these plugs to be between devices and the hub, because they had high rssi values (I have a room and garage on the opposite side of the house where the hub lives).
Which is why it was surprising to see the bathroom keypad using a route, because it's on the same side of the house as the hub.
tldr; why does zigbee do the things it does?
I was once told (and now fully believe) that ANY question beginning with "Why do THEY...?" the Answer is always: MONEY.
In the ZWave and Zigbee universe, "why do they..." tends to have The MESH as the answer.
The Mesh wants to be the largest possible sphere... or interconnected spheres.. and therefore the devices running a manufacturer produced algorithm in concert with the Hub do not want to use the closest, but rather the most distant router that has a zero error rate. That insures the mesh sphere grows with each router added.
If I knew that much about Zigbee and RF I likely would be retired already...
3 Likes
Ha! This is probably true... which stinks because the "biggest" doesn't help me - I need better stability on the other side of the house. The keypad on that side, and some of the lights, don't always fire like they're supposed to. If they're continuing to connect direct to the hub instead of a mid-point repeater, this is probably why.
I'm planning on replacing the "plugs" as repeaters with some zigbee light switches in key locations (I actually need to plugs in other places to work as... well plugs). Hoping they'll work better. The z-wave outlets and light switches work flawlessly. I thought about moving to a complete z-wave network, but the re-investment would be too much right now (plus the lack of any keypads, never mind z-wave ones).
Zigbee routing strategies use a 'link cost' which can take into consideration hop count as well as the LQI, an indicator of signal quality of the potential route. The route with the lowest 'cost' (and hopefully highest probability of successful packet delivery) gets chosen. Link costs are additive, so a single hop may trump a multi-hop route.
The lowest 'cost' routing device in the potential path may not be the one with the strongest RSSI, since the error rate of the link is also considered (RSSI is a 'simple' measure of RF energy during a measurement window -- including noise or competing networks if the frequency lines up). Strangely, while RSSI is measured in a standardized way, computing LQI is left up to the manufacturer though it always seems to be based on signal to noise ratio. Link costs are also used to determine now the parent of an end device gets chosen.
Lots of moving parts in the formula, and manufacturers still seem to be 'dialing it in' to get it to get different routing devices to play well together. See the text below fig. 3.36 in this link for a good explanation: Zigbee End Device - an overview | ScienceDirect Topics
1 Like
