Global Moderators group | Smart Home

CatmanV2

@Pabla very clever!

C

therealdb

I tried different things and after all I’ve just switched to my own emulated hue bridge, calling reactor HTTP endpoints. I was toying with the idea of sending MQTT commands, but HTTP just works. I did my own bridge because I have 100 switches/scenes/virtual switches mapped to Alexa and ha-bridge has not the ability to define multiple bridges on the same host, so I wrote mine

But ha-bridge should just work. Never tried HASS native hue emulation. I tried matter bridge and unfortunately Alexa will only see 20 devices.

CatmanV2

So far just keeps getting better. I thought I'd hit a snag yesterday wit the newly installed garage light switch being slow to trigger (IRO 6 seconds) but realised I was using the wrong HASS sensor attribute (durrr) once I sorted that, it's all sorted. Typical response times are sub second.

Some oddities in where I've migrated with some hacky virtual switches which I need to track down. I'd get rid of them but trying to expose HA entities to Alexa seems a bit hit and miss...

C

CatmanV2

That sounds very clever @Crille !. Does the light level actually increase in your case? I'd have more expected it to be constant once the lights are on? @Pabla is there actually a spike, or is the sensor reading the (one would expect) increased light level? This is assuming the sensor is within the zone of the lights....

C

therealdb

Back in the days I used an illuminance binary sensor to do this (linked to a fibaro relay), but now I’m using civil dawn/dusk and called it a day.

All that said, I’m still using an illuminance sensor indoor in my office to drive my blinds.

My logic is like the one you mentioned: once triggered, the low light state stays true for at least two hours. When driving lights/blinds, hysteresis is fundamental.

I was toying with the idea of using a time series, so I could get let’s say a trend and/or the avg in the latest 15 minutes or so, but it seemed overkill for this simple situation.

toggledbits

In the version you are using, it is still required; that's the docs leading the released code by a step (sorry). The version you are using also doesn't enforce limits well, so it allows values that could produce no result, or store more data than needed.

For example, given your retention of 60 and interval of 5, there would be r/i+1 = 13 samples in the series. But if you specify depth of 2, then only the most recent 2d-1 = 3 samples are considered... the other 10 samples don't contribute to the result value. A depth of 7 would be the best match for the given interval and retention (just mathematically, ignoring your semantic goals).

toggledbits

The previous post shows depth as null or not provided. Please specify both depth and retention, restart and wait at least one full interval, then copy-paste the attributes if a value hasn't been calculated.

toggledbits

@tunnus OK. Let's start here: copy-paste the device attributes for that VEC entity (remember to use fenced code block formatting when pasting in reply).

CatmanV2

Just popping this in here in case it's helpful to anyone else later. I've got several Tuya Wifi sockets that I'm getting rid of / replacing. Looking at which ones, if any, can be flashed to Tasmota:

SURFOU Smart Plug Wi-Fi Timer Socket with Energy Monitoring, Mini Remote Control Plug Works with Alexa, Google Home and SmartThings, Light Timers For Home Security, App Smart Life/Tuya, 13A : Amazon.co.uk: DIY & Tools

Are NOT flashable

C

CatmanV2

The migration has started. Pulling Z-wave devices and replacing them with Zigbee. Really successful so far. Much much snappier response. No range issues as each socket I'm adding acts as a router. Gonna have a play later see if I can flash the Tuya cloud plugs I bought to Tasmota....

C

Global Moderators

Posts

Member List