hi all,
im moving from insteon to hubitat with zooz dimmers.
electrician replaced all dimmers. so it's a fresh/new install.
I have buttons (zooz zen32) that Button Controllers calls scene like "2nd floor on", "basement off", "movie time", "all off"
and some Button Controllers are also calling rule machine that change zooz zen32 leds, but not all Button Controllers are calling rule machine.
im having a lot of issues.
when Button Controllers calls the scene Movie. it turns off all light on the main floor except living room that stays 100% and kitchen at 20%. it works as expected, but yesterday the living room, after 10 seconds, went down to 15% (WHY?!?!?!)
when Button Controllers calls all off. I have one or 2 lights that might take 10 seconds to turn off. sometimes one will dim to like 20% instead of going all off. (WHY?!?!! drives me crazy!)
I have about 36 zooz devices
no ghost device
I see re-route numbers going to like 60 in half a day and some MS in the 300-400 range on a couple devices. weak mesh?
did many power cycle (with and without a shutdown prior)
just performed a soft reset (and had 2 lights out of 36 that took 15 seconds to answer a all off.)
I must say, I miss my insteon. it had very little config option, but it was crazy reliable.
probably just some learning curve here.
I'm guessing a zwave issue (as @lewis.heidrick points out, the zwave details page will tell). But a hard shutdown of the hub can cause database corruption, which can lead to inconsistent behaviors. The easiest way to resolve it is to make a backup, store it locally, do a soft reset from the maintenance on port 8081, then do a restore. I'd say not a bad thing to do proactively if you've been bouncing the hub, just make sure you have a good backup or three.
I was wondering if that is still the case for the latest releases (or maybe it is just less of an issue). I understood that, a few releases ago, Hubitat may have switched to MySQL for their internal databases. Its my understanding that, with the atomic write features of MySQL, either a transaction is fully committed, or not at all, so if there is a power-off mid-transaction, the database will roll-back to the last completed transaction. So, your last update may roll back, but it shouldn't be a corruption. Even so, it seems reasonable that executing a "proper" shutdown from the device menu still is the better option when you have control over shutting down.
Good question. I know they had made improvements around database reliability, not sure if it's sufficient to prevent corruption in case of a hard down. But as you say good practice anyway.
I did a soft reset and restore a backup. didn't helped.
here are some logs showing I button controler press button 2 which calls a scene "2e off" + a machine rule to change 4 leds color (on zooz zen32)
first press, nothing for about 33 seconds. pressed again, took 14 seconds.
logs:
I generally agree with @lewis.heidrick's assessment. However, the signal strength on many of your devices is very poor (it is negative, implying that noise is greater than signal). So there's something noisy in the 900 MHz spectrum in your environment.
hum, aaiyar, thanks for your comment, you turned a lightbulb in my head.
I removed insteon and replaced with zwave.
but I still have 3-4 insteon devices connected.
and insteon is on 900mhz (915 to be exact according to this: Technology — Insteon )
ill hunt those devices down and remove them all.
honestly I picked z-wave because there is pretty much nothing on 900mhz now a days.
ok, all insteon stuff are unpluged. no change.
I turned on all lights in the house took about a minute according to logs.
programing is: button controler push calls the "dodo" scene first, then a rule machine that change 6 led color on zooz zen32 and call 2 more rule machine that each change led colors on 2 and 4 zen32
and why did it dim a light at 14% and the other at 99% ????? scene "dodo" is pretty clear they should be off! what is that???
actually, it took the device "RDC-Cuisine-D" that was on, and dim it to 14% and then later it turned in all on.
that's just none sense. the scene is saying to turn it off, not 14%, wait 30 ish seconds, and then on!
can my hub be faulty? im new in zwave and hubitat, but that can't be a zwave signal issue...
I think it still is. To test this, can you enable metering for your scene? And set the milliseconds of delay to be 200 ms. Run the scene manually see how it works. If it works, reduce the metering in steps down to just before it stops working.
it performed much better. I would need to try it a few times. but on the first try it was much better. why is adding a 200ms delay fixing it? (for my knowledge)
hum ok, I would have assume (hope) the hub would be smart enough to not shot itself in the foot?
so what would you recommand? try 150, 100, 50 until it breaks?
then apply that number to all my scenes?
is this something that should be done by everyone or it's for my house only due to my weak signal?
I was under the impression I disabled debug logging on all switches. is there debug login to turn off elsewhere?
ill install the zwave mesh and report back.
need opinion here. I think I may have found the issue.
i have a user app available here called [Switch Bindings] to do all my six 3 ways.
the scene "dodo" had all dimmers.
so every time one of the switches got turned off by the DODO scene, it was also calling the [Switch Bindings] to turn off the other switch. then the scene got to the other dimmer which called again the same switch binding.
I assume that doing this created a lot of zwave traffic and CPU cycle for hubitat.
so now I changed all my scene to only call one of the dimmers part of a 3 way and let the Switch Bindings handle the other dimmer of that 3 way.
and that might explain why I was seeing hubitat pushing 14% dim level on a led when the scene was for o%. maybe Switch Bindings kicked in when going from 100% to 0% and synced at 14%
I did 6-7 test calling (2nd floor on, basement on, main floor on, house off...) and worst case was about 3 seconds
im new to hubitat. am I all full of none sense here?
