openweather plugin ?

[ArcherS]

@therealdb said in openLuup: Shelly Bridge plugin:

I literally have bought anything from them, but I've not fully deployed every device. I'm still waiting for my Uni and EM to be inserted. the EMs will soon monitor my AC, so I could detect if it's running or not (I have to use two switchbots to turn it on/off, because it's still under warranty and I could not mess with the original thermostat).

@therealdb I still have an EM that I will setup over time to monitor the consumption of the spa and the HVAC.
I also have a few more Shellies inbound in the mail; some Shelly 1's, a few 1PMs and a Button1. The plan is to replace a few aeging Aeotec relays that do not behave properly with the 1PMs.
The Button1 I plan to use instead of a really old Zwave.me wall controller.

All that said, I'm voting for automatic creation of child temp/humidity sensors, and for Uni to create relays and inputs separately. That's what most people will do, anyway.

I can second the thought on autocreation of temp/humidity and relay/input for the Uni if it is feasible to maintain. However not being a developer I am happy with what I get!

The native Shelly and Tasmota support in OpenLuup together with the Mqtt support is a huge and really cool addition to the platform!

[akbooer]

@archers said in openLuup: Shelly Bridge plugin:

The Button1 I plan to use instead of a really old Zwave.me wall controller.

Yup, done that too. OK if you can get used to the 2 second delay (unless on USB power.)

[akbooer]

@archers said in openLuup: Shelly Bridge plugin:

I can second the thought on autocreation of temp/humidity and relay/input for the Uni if it is feasible to maintain.

Not, fundamentally, any problem, but I haven’t (yet) got a Uni.

[ArcherS]

@akbooer said in openLuup: Shelly Bridge plugin:

Yup, done that too. OK if you can get used to the 2 second delay (unless on USB power.)

I have now included the Button1 and it works ok, it added without problems in OpenLuup. No child devices, but I assume that is the way it should be.

I think I will keep it attached to USB power. I have power available where the button is located and this gives more or less instant actions. I also noticed that if it is not on USB in some cases it does not connect as it should when going out of sleep when you push the button.
I assume that wifi is not the best technology for battery powered devices.
So far I am using a direct action from the button to the 1PM that it should control.

[akbooer]

@archers said in openLuup: Shelly Bridge plugin:

I assume that wifi is not the best technology for battery powered devices.

No, not really. That’s what Zwave and Zigbee were supposed to be about. But I have to say that in terms of all the HA technology I’ve had (X10 / Zwave / Zigbee) it all pales into insignificance compared to Shellies and WiFi – especially in terms of setup and the fact that you don’t need a controller at all.

[therealdb]

@archers said in openLuup: Shelly Bridge plugin:

I think I will keep it attached to USB power. I have power available where the button is located and this gives more or less instant actions. I also noticed that if it is not on USB in some cases it does not connect as it should when going out of sleep when you push the button.

yep, I've them inside my cars, so USB powered. It will takes about 3-4 seconds at boot for them to jon the WiFi network and send an MQTT message. My use case is not normal and I'll probably swap them with nodemcu devices in the future, but overall for 10 eur battery included I'm very satisfied.

I'll install Shellies into my sister-in-law house this year, because they really want home control and not home automation, and Shelly is the least overkill solution to this problem. No hub required for very basic automation is not bad, for "normal" users.

[akbooer]

@akbooer said in openLuup: MQTT server:

I don't have any HT devices,

...but I do now, and I've just updated the Shelly plugin to support individual temperature and humidity child devices for each H&T, and also a battery level for the parent device.

A bit disappointed with the quality of the H&T case, it seems inferior to the excellent Button 1 – but it's so small and innocuous that perhaps it doesn't matter. Aside from that, it's a fine little device (although I've not checked the calibration accuracy, I see that they do include a user-definable offset for both H & T readings.) If the battery lasts as well as they say, that'l be fine.

[ArcherS]

@akbooer today I added a Shelly Dimmer2 replacing a really old Fibaro dimmer that died. The Shelly dimmer seems like a nice device so far.

It is added into OpenLuup as it should:

The following variables are mapped:

announce:

{"id":"shellydimmer2-nnn","model":"SHDM-2","mac":"nnn","ip":"192.168.1.nn","new_fw":false,"fw_ver":"20210226-115010/v1.9.6-dimmer2@1873d25e"}

light/0/status:

{"ison":true,"source":"http","has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"mode":"white","brightness":80}

However no child devices are created for the dimmer. Could this be added to the Shelly bridge?

(I am running OpenLuup v 21.8.16.)

[akbooer]

Yes, I don't believe that I've implemented the dimmer... I certainly haven't got one!

I'll take a look – thanks for the excellent configuration information!

[akbooer]

@ArcherS

This is going to be hard without having a dimmer. You're not in the UK, are you? I didn't really want to buy one (£22 UK price) because I have absolutely no need of one.

Any chance that anyone has got a spare one they can send me?

[therealdb]

@akbooer I have a virtual server just to test my own integration. I think it’s a safer investment for you to validate any device you don’t have access to. The doc is pretty good and it’s not complex to replicate both http and mqtt messages in a fake implementation.

[ArcherS]

@akbooer sorry, no I am in Sweden.
I only have one dimmer unit so far and it is in my son's room, he will not like being without ceiling lights this time of the year in our parts of the world.

[akbooer]

OK, so we’ll have to do this in an iterative way, with me making a few mistakes.

[akbooer]

@ArcherS

Just for you, I’ve bought one of my own. Hasn’t arrived yet, but I’ll be right on it when it does.

AK

[ArcherS]

@akbooer top notch service as always! Hopefully you will get good use of it also.
So far I am happy with mine. The dimmer supports all kind of switches. I use it with a spring loaded wall switch in "one button mode", i.e. as a push button with push-and-hold for dimming.

As a side note I am still on 1.9.x on my Shellies since I did not get mqtt to work with the new firmware. On the EU Shelly support site it is very easy to set up an ota-url for flashing older versions on a device.

[akbooer]

@therealdb

I missed your post, somehow. As you see, I’ve gone for the hardware rather than a virtual solution, but I certainly won’t be doing that for all new Shellies!

Any details to share on how you’ve done this?

[therealdb]

@akbooer I just wrote a super simple http server replying the same way Shelly devices are doing. Plus, I send mqtt messages every x secs to my dev mqtt broker, to replicate the same behavior. I was using this while developing the support for mqtt inside my own system.

I’ve done the same way for opensprinkler, in order to avoid messing with my sprinklers.

It’s done in C#, but it should be easy with anything else.

[Buxton]

@akbooer is there any chance on you decoupling the tasmota and shelly bridges from openLuup. I'm asking because if the bridges were stand alone plugins, they could be used as quasi templates for other MQTT devices. For example, my BlueIris server MQTT messaging now maps to individual Vera devices that represent BlueIris cameras (created with the Tasmota bridge), but the functionality of each vera device is limited, due to the way in which the tasmota bridge creates its child devices. With a stand alone plugin, I could revise a clone of the plugin to include more specific functionality for a given MQTT source.

Everything MQTT wise works well now, so no real need to do this, but it strikes me that it would be a cleaner approach to handling MQTT in openLuup and the myriad IOT devices that will make use of the protocol.

[akbooer]

They're closely coupled so that they can auto-install if any of their devices are detected, rather than having to download a bridge plugin separately. As such, I consider them to be an integral part of the system (a change, certainly, from my previous device-agnostic approach, but part of my personal move away from ZWave.)

The MQTT bridge functionality is totally general, and I would have thought that this was a better place to start.

...or am I missing your point, here?

[akbooer]

@archers said in openLuup: Shelly Bridge plugin:

@akbooer top notch service as always! Hopefully you will get good use of it also.

Well, we'll see (the device arrived yesterday)...

Latest development version of openLuup (v21.11.2) has an initial attempt to service the Dimmer2 device:

• inputs are handled exactly as the switch device – so, essentially, as a scene controller showing the latest activated scene: short press; long press; etc... This should work for both input switches (if you have any with two.)
• on/off button on the control panel should work for the dimmer bulb.
• slider control is not yet implemented.

...my current issue is that, although I now have the Shelly Dimmer2 device, I don't have any dimmable bulbs! Everything I have is LED, and they're either non-dimmable or smart devices anyway. In particular, I can't tell whether the power and Watts parameters work correctly for the dimmer.

So I'd appreciate a listing of any bugs that you find, and I'll continue to work on the slider control.

Incidentally, I've update to the latest firmware for this device: 20210909-150154/v1.11.4-DNSfix-ge6b2f6d since it came with a very old version that didn't even publish the model number. It seems to work fine, but I've not updated any other of my devices.