I bricked my Blue Series Smart 2-1 Switch

I installed the switch once and it worked for a while, until it didn’t. So the wiring is not the issue.

I was trying to expose the state of the dimmer brightness. In HA, I could adjust a slider below the on/off toggle and the blue LEDs on the switch would follow. If I adjusted the Inovelli switch itself, the slider in HA would follow. However, I could never find an attribute to be able to read this brightness value.

This is what I was looking for, as an example:

{{ state_attr(‘light.inovelli_switch’, ‘brightness’) }}
255

When do the colors cycle, only when the load is off or always after you air gap it?

I recognize you moved off ZHA but for anyone else searching in the future at least, it should show up but you may only see brightness when the entity is on (the level, on_off child of the device) looks like this in developer tools -

Famous last words. I’ve absolutely had it work until it didn’t and it was wiring.

Best triple checking/reseating wiring to eliminate all possible issues there. I agree with chack that the switch is resetting itself due to not enough load or improper wiring.

1 Like

Not to say you don’t have a bad switch. It very well could be a bad switch; there’s bound to be one failure in the batch.

With that being said, we saw many posts during the Red Series phase and there were several wiring issues. Also, there were a few that have the wire push through the hole, but on the outside of the clamp. The wire was basically loosely installed. I believe it led to @Bry or someone else illustrate the correct method of screwing down the wire.

Obviously if you’ve double/triple checked the wiring and see no issues with the connections, I would start a RMA for it.

1 Like

When I had it working with ZHA I remember off_with_transition, friendly_name and supported_features and perhaps some others. If I had seen brightness then my life would be very different now.

Today I re-wired the switch so that the load joined the line in. I’m using Hue smart bulbs, so this should work fine. Nothing changed. The switch powers up, cycles through CYAN, off, YELLOW, off and then just sits there with very dim BLUE and does not respond to any input whatsoever.

IMG_4196

I moved the switch to the garage and tried a completely different circuit. Same result.

IMG_4198

Yea would start a RMA if it was me. Good news is there should be plenty of stock for RMAs.

1 Like

I just noticed with my Philips Hue bulb that brightness: is not an attribute until the bulb is ON. Perhaps that was the issue I was having. I can only speculate as I don’t have a working switch at this time, but I think that brightness may only be exposed as an attribute if the switch is driving a load. Since I was using the switch in Smart Bulb mode, that may explain why there is no brightness attribute… ?

If this is the case (again, this is speculation), then I would request that this be modified so that the brightness of the LED (height of the bar) is exposed as an attribute at all times, regardless of the on/off state of the switch itself.

That’s correct I can confirm it only displayed for me as well when on. Haven’t used SBM yet myself but will give that a shot to check as well.

I’ll see what can be done from the HA or ZHA side of things, I don’t believe this comes back to the dimmer itself but rather how HA is working. For example, you can click the entity icon and get the brightness slider, etc even if it’s off so I’m sure there’s a way of getting that -
image

Edit to add - brightness is showing up for me still with SBM enabled. It tracks as I hold the dimmer up/down and refresh state, however the attribute goes away when the device is ‘off’ (load stays powered because SBM obviously). Is the goal to use automation to match LED bar brightness to the Hue bulbs because you can’t use binding (if your Hue bulbs are using a Hue hub instead)?

1 Like

That is correct. I want to retain the ability to use the Hue app and therefore I can’t use binding. I wanted to have the brightness of the Hue bulbs (room) track the brightness of the Inovelli dimmer. For this to happen, the brightness needs to always be exposed even when the switch is in Smart Bulb or off.

Ok so, the issue here is ultimately that “it’s complicated” re the brightness attribute specifically. What should happen is that when the light is on, you’ll have the brightness attribute exposed, and when the device turns off it goes away (my understanding is this is in accordance with the Zigbee spec, as brightness commands can’t be sent to an ‘off’ device). The workaround in HA is that when the device turns off, you should have an off_brightness attribute that will update with the previous value of brightness (this attribute becomes null when brightness is ‘on’). However in my personal testing I ended up having off_brightness stuck to null after a point regardless of the switch being ‘on’ or ‘off’.

All that said, the recommendation I was given to pass on is to use this blueprint to work off the events to keep them in sync.

1 Like

The Zigbee Level Control Cluster spec supports “Move To Level” without changing switch on/off state. Its up to the driver/handler to decide whether to implement that option or not.

1 Like

Hey Paul,

Wanted to set some expectations here as maybe there was a miscommunication of some sort.

The title of this thread is that you bricked your switch therefore I’m not sure what you expected of us. If we set the precedent that you can brick a switch and we will replace it no questions, then we would have a tough time staying in business.

I don’t see any correspondence in tickets asking about an RMA nor any sort of troubleshooting questions, etc.

I know someone in the thread mentioned to RMA it, but that wasn’t an Inovelli employee. It appears that it was sent out of the blue when no one from our side said to send it in. Again, I can’t find any record in our tickets. It’s hard to diagnose a switch that just magically shows up with no notes.

In addition, I’m only seeing a message to Nate on February 10th where you asked about this switch and Nate responded the same day.

It’s possible I missed some conversations outside of tickets where we said we’d replace it, I’m just going off the communication I can readily see.

I guess what is the desired outcome here?

3 Likes

The more I think about this situation, it seems like both of us could have improved our communication and I’d at least like to apologize for our part.

While everything above still holds true and I think I got overly defensive because it was implied that we didn’t get back to you for months after we asked you to send in the switch on your own dime, which wasn’t true.

I do think our team should’ve reached out to you when we received the switch to at least troubleshoot with you and ultimately let you know the determination on the RMA. I’m not sure why that wasn’t done, but I’ll talk to the returns people about that.

That said, I have an extra personal switch that I ended up not needing (decided to beta test the Z-Wave one) that I can send to you as a peace offering if you’ll accept. If so, please just respond to that ticket or shoot me and/or Courtney a PM and we’ll get it out to you.

Again, very sorry for the mixup and I think we can both learn from this experience.

5 Likes

Regarding making the switch act as a dimmer for Hue lights, I found the best solution to be the following:

Trigger is when the state of the Inovelli switch changes.

Condition

condition: template
value_template: |-
  {{  states.light.inovelli_test_switch.last_updated >
        states.light.backyard.last_changed }}
enabled: true

Action

service: light.turn_on
entity_id: light.backyard
data_template:
  brightness: >
    {{ state_attr('light.inovelli_test_switch', 'brightness') | default(0, true)
    }}

This allows you to use the dimmer on the switch to set a brightness level. When you up_release or down_release, this automation then takes the brightness level of the switch and applies that to the light. There is no direct ability to dim the light, as you need to release to then see the light change… but this is by far the best solution I have been able to come up with.

Literally the exact same thing had happened to me. All I did was switch from Home Assistant ZHA to Zigbee2MQTT so I could use the double tap actions to trigger scenes. I too am left with a dead switch doing the exact same thing. I genuinely can’t understand why that wouldn’t constitute a warranty claim. What if I had sold this switch used and someone decided to use it with Z2M after I had used it with ZHA?

Perhaps there is at least a JTAG protocol we can re-flash the firmware with to bring these things back to life?

As a followup and answer to my own question, I wanted to close this thread.

I believe that the issue was caused by the fact that I had paired the switch using ZHA and then tried to pair the switch again using Zigbee2MQTT. I can’t be 100% certain, and this is only educated speculation.

Regarding the air gap switch, I have taken the switch apart (as instructed by support to fix the stuck ground terminal plate issue) and it appears that the air gap switch breaks the incoming connection to the LINE in (which makes complete sense). You can see this for yourself in my video where I show the insides of the 2-1 Switch. You can see the traces on the circuit board leading to the air gap switch. For the person who reported that they still had power when the air gap was open, I would suggest they check that the line and neutral have not been swapped.

Inovelli Blue Series Smart 2-1 Switch Review and guide to programming