Driver dilemma - Samotech SM323 dimmers

🛎️ Get Help Devices
1

Hi all. I'm a recent adopter of Hubitat and have been linking it to the many Samotech SM323 Zigbee dimmers I have. These are standard UK dimmer plate modules - push on / push off and rotate to dim. When adding these dimmers, Hubitat reports them as 'RGBGenie Micro Zigbee Dimmer' - and that driver work really well, apart from one thing. As I've seen other users post, they don't report their level properly.

I can use the generic zigbee dimmer driver and that does work perfectly, including reporting its level. However, I really like the level pre-staging (and default transition time) which can be done with the RGBGenie Micro Zigbee dimmer driver, but can't be done with the generic driver.

My actual use case for this is for lights and a rule control of a ceiling fan in a bathroom. I'm using the rule machine to control a Zigbee switch for the fan based on the dimmer switch position and level - if the light is on and the dimmer level is at or above 10%, the fan comes on, otherwise it's off. The dimmer level section of the rule is because my kids tend to just turn the dimmers all the way down rather than switch them off, so this prevents the fan running 24/7!

I'm also using the Mode Lighting app to set the level of this same dimmer to around 8% during night mode so if someone gets up to use the bathroom at night, the light only comes on at a glow instead of blindingly bright. The 10% level in the fan control rule also stops the fan coming on at night - it's quite noisy!

This is where I have a dilemma over drivers. If I use the generic driver, all works as it should except that because it doesn't have level pre-staging, when switched on at night the dimmer comes on to its previous (bright!) level before dimming down to 8%. If I use the RGBGenie driver, the light control is perfect, so the level pre-staging makes the light come on directly on to 8%, but the fan control doesn't work because the dimmer's not reporting its level.

With the RGBGenie Micro Zigbee driver, changing level on the dimmer (physically or digitally) works perfectly, but I get this message in the logs:

[error] java.lang.NullPointerException: Cannot execute null+null on line 240 (method parse)

Which I assume is responsible for the non-reporting of its level?

Of course, all of these are 'first world problems' :wink: But I'd really like to get it working as intended. Does anyone have any thoughts on any solutions? I'm inclined to use the RGBGenie driver to keep the level pre-staging and transition time control - but the absence of full fan control and the error entries in the log every time one of these dimmers change level (I have 16 of them in the house!) would bother me!

Thanks in advance for any help you can give me.

2

Hi there. Did you ever get anywhere with this as I have a slight similar problem. I've noticed that when I physically turn the dimmer on (by pressing the button) then the device within the app doesn't recognize the dimmers state as being on. Only when I alter the brightness by turning the dimmer (after turning on by pressing) does the state update to "on". I've tried the following 3 drivers but they yield the same result:

  • Generic ZigBee Dimmer
  • RGB Genie dimmer
  • ZigBee generic dimmer (with presence)

NB, the off command and state is recognised in the app once the button is pressed to the off position but not the on position

My use case for this is similar, upon physically turning the light on, I want an action to occur but it won't because the hub doesn't seem to recognise the switch has been turned to the on state.

Very odd that turning off is flawlessly recognised by the hub. I appreciate this may be a driver or dimmer hardware issue, does anyone know which one is at fault. Please help.... Appreciated...Stu

3

Hi Stu,

Yes - kind of!

I gave up with the level pre-staging and just used the generic Zigbee dimmer driver.
I have a lot (20-30 ish!) of these Samotech SM323 dimmer modules around my house. Almost all of them report themselves as 'Dimmer-Switch-ZB3.0' in their model field and report their on/off state to Hubitat correctly.

I bought a further two in July 2022 (although I didn't get round to doing anything with them until Feb 2023) which reported themselves as 'HK-DIM-A' - and these had the exact issue you describe; they wouldn't report themselves as 'on' until the brightness was tweaked. Reporting an 'off' state always worked fine. I contacted Samotech about this at the time, and they said:

"We are expecting a new stock at the end of next month with a newer firmware. Please contact us again in one month time and we should be able to replace the modules for you if still required."

My use case for these was almost identical to what you describe above, and once I realised these two modules weren't reporting an 'on' state, I tried reading their level instead - but of course that didn't work as they report their dimmer level regardless of whether they're 'on' or 'off' ( I was hoping for a level=0 when 'off' and level=>1 when 'on').

As I have a lot of modules where I don't rely on correct reporting of on/off state, I took the easy option and physically swapped the two newer modules with a couple of older ones located where I didn't need on/off reporting - so never followed it up with Samotech. Fair play to them for offering a swap, though.

So - I think it's probably an issue with the firmware on a certain batch of the SM323 dimmer modules - but I never followed it up as I could solve my problem by swapping some modules around the house.

I do have a few even newer ones with another, different, model name/number reported. I'm away from home at the moment so can't check, but if i remember correctly, something in the softwareBuild fields of these even newer ones creates errors in Hubitat's log (A letter in there rather than purely numeric I think?). As it's only fields in the device reporting which upsets Hubitat rather than anything operational, I've never been too bothered, as it doesn't stop it all working! I've not needed on/off reporting on these ones, though, so haven't checked whether it works correctly with these ones. I'll have a look when I get back home at the weekend.

So - long story short - it might be worth contacting Samotech as it sounds like it may well be firmware in the batch from which your dimmer modules come causing your woes. I'd be interested to know when you bought them and what they report their model to be.

For what it's worth I've had these modules throughout my house for 3+ years now and other than the absence of correct reporting on two of them, they've all worked flawlessly.

Good luck!
Paul

4

Hi @Paul.S thanks for your detailed and lengthy reply, very appreciated. Everything you've said stacks up and it mirrors my scenario exactly.

Oddly, just like you, I bought these dimmers several months back and I too have only just got round to installing them. They are model HK-DIM-A which is where the issue appears to lie. My earlier purchased versions work seamlessly and they're model Dimmer-Switch-ZB3.0. It looks like my situation mirrors yours exactly.

Next steps are to contact Samotech :slight_smile:

5

@Paul.S for info, I sent my faulty 323's back and they gladly replaced them with their upgraded SM323 V2's. I have them seamlessly working with the GE ZigBee Dimmer Driver. They appear to be a good piece of kit and offer the option of a neutral wire which I assume is to help circumvent the need for a bypass if the power draw is extremely low. Thanks again.

Oh, hang tight, all is not what I first thought. I'll report back

6

Ok folks, so after much testing on and off. The SM323 MK2 seems to randomly turn itself off when physically turned on when the dial is rotated. This occurs immediately and within a second of turning the dimmer dial on. This is an inconsistent issue but definitely occurs. Does anyone have a solution to this. I thought this product was excellent but this bug frustrates me. See logs :slight_smile:

1000023976
10000239761067×1081 186 KB