markus7017 / myfiles Goto Github PK

I have connected a reed contact as external switch to a Shelly 1 Addon as sensor for position of a garage door. The external switch is reflected in the JSON output, but not in OH3

Full JSON Output (provided by Sven_S):

{"wifi_sta":{"connected":true,"ssid":"SECRET","ip":"192.168.xxx.xxx","rssi":-61},"cloud":{"enabled":true,"connected":true},"mqtt":{"connected":false},"time":"00:19","unixtime":1632781182,"serial":24,"has_update":false,"mac":"40F520XXXXXX","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"ext_switch":{"0":{"input":0}},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"source":"timer"}],"meters":[{"power":0.00,"is_valid":true}],"inputs":[{"input":0,"event":"","event_cnt":0}],"ext_sensors":{},"ext_temperature":{},"ext_humidity":{},"update":{"status":"idle","has_update":false,"new_version":"20210909-144114/v1.11.4-DNSfix-ge6b2f6d","old_version":"20210909-144114/v1.11.4-DNSfix-ge6b2f6d"},"ram_total":50872,"ram_free":35536,"fs_size":233681,"fs_free":149596,"uptime":6431}

Relevant Detail:

Door closed (Switch open) => "ext_switch":{"0":{"input":0}}
Door open (Switch closed) => "ext_switch":{"0":{"input":1}}

No function in OH3. Not showing up as relay or sensor.

Hello,

I just switched to OH3 and almost successfully installed MAGENTATV Binding 3.1.0. However, for the switch POWER, Openhab only recognizes the ON status. OFF is ignored. I can switch the receiver on and off via Openhab, but Openhab does not recognize the OFF when I switch off the receiver directly at the device.

In version 2.5.1 this still worked.

Is this known?

The issues implements status#input1 of type CONTACT to indicate the status of the reed add-on

Shelly 2.5 roller status is not updated or updated with delay. OH 3.4

Openhab 4.0.3 stable as openhabian on Pi 4B
Shelly binding installed from UI
Shelly plus 2pm version 1.0.3 with sensor add-on and DS18B20
When discovering the Shelly and adding it to the things DB the temperature sensor in the add-on is added as a channel only if the Shelly is in switch mode. If in cover mode then the Shelly reports the add-on during the thing add process but the channel never gets created.

Relevant messages when in switch mode
2023-09-24 19:36:20.445 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellyplus2pm-c049ef8b2474: Shelly Add-On detected with at least 1 external sensor 2023-09-24 19:36:22.667 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplus2pm-c049ef8b2474: NotifyStatus update received: {"id":1719399656,"src":"shellyplus2pm-c049ef8b2474","dst":"shellyplus2pm-c049ef8b2474","params":{"ble":null,"cloud":{"connected":false},"mqtt":{"connected":false},"sys":{"mac":"C049EF8B2474","restart_required":false,"time":"19:36","unixtime":1695573382,"uptime":86,"ram_size":257964,"ram_free":112932,"fs_size":458752,"fs_free":143360,"cfg_rev":10,"available_updates":null,"webhook_rev":2},"wifi":{"sta_ip":"192.168.10.230","status":"got ip","ssid":"HomeAuto","rssi":-46},"input:0":{"id":0,"state":false},"input:1":{"id":1,"state":false},"switch:0":{"id":0,"source":"init","output":false,"apower":0.0,"voltage":227.6,"current":0.0,"pf":0.0,"aenergy":{"total":0.0,"by_minute":[0.0,0.0,0.0],"minute_ts":1695573380},"temperature":{"tC":67.0,"tF":152.6}},"switch:1":{"id":1,"source":"init","output":false,"apower":0.0,"voltage":227.7,"current":0.0,"pf":0.0,"aenergy":{"total":0.0,"by_minute":[0.0,0.0,0.0],"minute_ts":1695573380},"temperature":{"tC":67.0,"tF":152.6}},"temperature:100":{"id":100,"tC":32.8,"tF":91.1}},"result":{"ble":{},"cloud":{"connected":false},"mqtt":{"connected":false},"sys":{"mac":"C049EF8B2474","restart_required":false,"time":"19:36","unixtime":1695573382,"uptime":86,"ram_size":257964,"ram_free":112932,"fs_size":458752,"fs_free":143360,"cfg_rev":10,"available_updates":{},"webhook_rev":2},"wifi":{"sta_ip":"192.168.10.230","status":"got ip","ssid":"HomeAuto","rssi":-46},"input:0":{"id":0,"state":false},"input:1":{"id":1,"state":false},"switch:0":{"id":0,"source":"init","output":false,"apower":0.0,"voltage":227.6,"current":0.0,"pf":0.0,"aenergy":{"total":0.0,"by_minute":[0.0,0.0,0.0],"minute_ts":1695573380},"temperature":{"tC":67.0,"tF":152.6}},"switch:1":{"id":1,"source":"init","output":false,"apower":0.0,"voltage":227.7,"current":0.0,"pf":0.0,"aenergy":{"total":0.0,"by_minute":[0.0,0.0,0.0],"minute_ts":1695573380},"temperature":{"tC":67.0,"tF":152.6}},"temperature:100":{"id":100,"tC":32.8,"tF":91.1}}} 2023-09-24 19:36:22.697 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellyplus2pm-c049ef8b2474: Adding channel sensors#temperature1
Relevant messages when in cover mode
2023-09-24 19:43:58.649 [DEBUG] [y.internal.handler.ShellyBaseHandler] - shellyplus2pm-c049ef8b2474: Shelly Add-On detected with at least 1 external sensor 2023-09-24 19:44:00.890 [DEBUG] [g.shelly.internal.api2.Shelly2ApiRpc] - shellyplus2pm-c049ef8b2474: NotifyStatus update received: {"id":212392860,"src":"shellyplus2pm-c049ef8b2474","dst":"shellyplus2pm-c049ef8b2474","params":{"ble":null,"cloud":{"connected":false},"mqtt":{"connected":false},"sys":{"mac":"C049EF8B2474","restart_required":false,"time":"19:44","unixtime":1695573840,"uptime":43,"ram_size":257688,"ram_free":109772,"fs_size":458752,"fs_free":143360,"cfg_rev":11,"available_updates":null,"webhook_rev":3},"wifi":{"sta_ip":"192.168.10.230","status":"got ip","ssid":"HomeAuto","rssi":-42},"input:0":{"id":0,"state":false},"input:1":{"id":1,"state":false},"cover:0":{"id":0,"source":"init","state":"stopped","apower":0.0,"voltage":226.6,"current":0.0,"pf":0.0,"aenergy":{"total":0.0,"by_minute":[0.0,0.0,0.0],"minute_ts":1695573840},"pos_control":false,"temperature":{"tC":66.9,"tF":152.5}},"temperature:100":{"id":100,"tC":32.8,"tF":91.1}},"result":{"ble":{},"cloud":{"connected":false},"mqtt":{"connected":false},"sys":{"mac":"C049EF8B2474","restart_required":false,"time":"19:44","unixtime":1695573840,"uptime":43,"ram_size":257688,"ram_free":109772,"fs_size":458752,"fs_free":143360,"cfg_rev":11,"available_updates":{},"webhook_rev":3},"wifi":{"sta_ip":"192.168.10.230","status":"got ip","ssid":"HomeAuto","rssi":-42},"input:0":{"id":0,"state":false},"input:1":{"id":1,"state":false},"cover:0":{"id":0,"source":"init","state":"stopped","apower":0.0,"voltage":226.6,"current":0.0,"pf":0.0,"aenergy":{"total":0.0,"by_minute":[0.0,0.0,0.0],"minute_ts":1695573840},"pos_control":false,"temperature":{"tC":66.9,"tF":152.5}},"temperature:100":{"id":100,"tC":32.8,"tF":91.1}}}

Hey Markus,
great Job, but with the actual 2.5.11-SNAPSHOT.jar I got this error.

General Error: Can't create object of type CNChargerInfo: json is null!

and thing carnet thing goes offline.

Have you any ideas to fix?

Hi Markus,

after updating and restarting my PI to Opnehab M5 I'm not receiving any informations from my car.
Also tested the last snapshot.
Binding is online, not showing any errors. Reinstalling of the binding does not help.

Do you have any idea??
Thanks in advance
Martin

Incorrect values in items in totalKWH 1/2/3
here is a status from device:

{"wifi_sta":{"connected":true,"ssid":"IoT","ip":"192.168.10.34","rssi":-44},"cloud":{"enabled":true,"connected":true},"mqtt":{"connected":false},"time":"00:06","unixtime":1670454380,"serial":40107,"has_update":false,"mac":"40F52000B6BF","cfg_changed_cnt":0,"actions_stats":{"skipped":0},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"is_valid":true,"source":"http"}],"emeters":[{"power":642.10,"pf":0.92,"current":2.89,"voltage":241.38,"is_valid":true,"total":18039107.3,"total_returned":5362303.9},{"power":1123.68,"pf":0.84,"current":5.47,"voltage":244.26,"is_valid":true,"total":18136912.4,"total_returned":6113606.3},{"power":304.42,"pf":0.64,"current":1.94,"voltage":244.44,"is_valid":true,"total":14161565.6,"total_returned":105.4}],"total_power":2070.20,"emeter_n":{"current":0.00,"ixsum":4.30,"mismatch":false,"is_valid":false},"fs_mounted":true,"v_data":1,"ct_calst":0,"update":{"status":"idle","has_update":false,"new_version":"20221027-110030/v1.12.1-ga9117d3","old_version":"20221027-110030/v1.12.1-ga9117d3"},"ram_total":49928,"ram_free":31364,"fs_size":233681,"fs_free":152859,"uptime":573585}

Here are values from OH items:
64941292800.000 J
65293862400.000 J
50982177600.000 J

Total returned KW/H looks fine. Values are same as status from device.

This device supports 2 relays in cover mode (Dual Cover) and has the power meter capabilities

First of all: Thank you for this binding. With this I'm mostly able to get feature parity with the information and control in the native We Connect app.

But there are some channels that isn't working or responding as expected on my E-Up. I use the 20220930 snapshot org.openhab.binding.connectedcar-3.3.0-SNAPSHOT.jar. The channels are:

• status#maintenanceRequired: This is always ON, though no indication of required service is shown in the car or in We Connect.
• status#vehicleLights: No data, always NULL.
• status#parkingLight: Ditto. Always NULL. This is reported in We Connect, so I assume it should be available.
• control#climater: Dumps error to log. More on this below.
• control#targetTemperature: This is a read only value on this binding, though I am able to set the climater temp in We Connect.
• status#doorsClosed: No data. Always NULL. Not sure if this supposed to work. The individual doors, hood and hatch are reported correctly.
• control#targetChgLvl: Unable to control, always NULL.
• control#charge: It works, but dumps error to log. More on this below.

The control#climater channel error

This is the most important show-stopper. Automating or controlling the climate from openhab is a must have.

When turning this on and off the following error log is dumped:

2022-11-06 22:37:28.402 [INFO ] [ar.internal.handler.ThingBaseHandler] - VW_EUp: Status from service rclima_v1.P_START_CLIMA_EL: API call failed POST https://msg.volkswagen.de/fs-car/bs/climatisation/v1/VW/DE/vehicles/****/climater/actions (HTTP 400 Bad Request), result = {"error":{"errorCode":"gw.error.validation","description":"Invalid payload"}}

The error code, pretty printed:

{
    "error": {
        "errorCode": "gw.error.validation",
        "description": "Invalid payload"
    }
}

The control#charge error

When flipping this switch, the following stack trace is dumped to log:

2022-11-06 23:03:06.510 [WARN ] [ar.internal.handler.ThingBaseHandler] - VW_EUp: General Error: queuePendingAction(): requestId must not be empty!
java.lang.IllegalArgumentException: queuePendingAction(): requestId must not be empty!
        at org.openhab.binding.connectedcar.internal.api.ApiRequestQueue.queuePendingAction(ApiRequestQueue.java:70) ~[bundleFile:?]
        at org.openhab.binding.connectedcar.internal.api.carnet.CarNetApi.queuePendingAction(CarNetApi.java:531) ~[bundleFile:?]
        at org.openhab.binding.connectedcar.internal.api.carnet.CarNetApi.sendAction(CarNetApi.java:510) ~[bundleFile:?]
        at org.openhab.binding.connectedcar.internal.api.carnet.CarNetApi.controlCharger(CarNetApi.java:405) ~[bundleFile:?]
        at org.openhab.binding.connectedcar.internal.handler.CarNetVehicleHandler.handleBrandCommand(CarNetVehicleHandler.java:105) ~[bundleFile:?]
        at org.openhab.binding.connectedcar.internal.handler.ThingBaseHandler.handleCommand(ThingBaseHandler.java:311) [bundleFile:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.InvocationHandlerSync.invoke(InvocationHandlerSync.java:59) [bundleFile:?]
        at com.sun.proxy.$Proxy432.handleCommand(Unknown Source) [?:?]
        at org.openhab.core.thing.internal.profiles.ProfileCallbackImpl.handleCommand(ProfileCallbackImpl.java:80) [bundleFile:?]
        at org.openhab.core.thing.internal.profiles.SystemDefaultProfile.onCommandFromItem(SystemDefaultProfile.java:48) [bundleFile:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
        at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
        at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:154) [bundleFile:?]
        at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]

But the car do respond to starting and stopping the charger, so this trace is related to something else.

Hi there,

I think I found a shelly binding bug. I try to explain:

I wondered, that in my influxDB persistence, only, when I restart a shelly Device, or restart the thing, I get a 0 Watt into the database. So I tried to figure out why this is happening and I think I found it. It is because ItemStateUpdatedEvent and ItemStateEvent is getting the last none zero value.
See screenshot attached.

Perhaps there is a simple fix for that. My grafana graphs are looking weird without a zero. I am using a persistence rule with at everyUpdate option. Also I do not see any continuous updates, when 0 Watt is on for a long time. But perhaps that's fine.

I hope you will understand the problem. If not, feel free to ask.

cheers
Andreas

The Plus/Pro series has the so-called range extender mode, which can be used on use one Shelly as a hub with another, which doesn't has proper w-lan coverage. In facts it's kind of a NAT linkage (secondary device is addressed using :). Actions and notifications will then be routed through the primary device. The binding will detect this configuration and add additional things for tose secondary devices.

Hello,
I tried to add a shelly plus 1 pm device with OH 3.1.0 but ist won't discover... any hint?
Reagrds, Dirk

The counter part of the Gen1 Shelly UNI is the Gen2 Plus UNI, which adds additional capabilities.

Installing the ConnectedCar Plugin as user addon in OH3 (3.2.0) I got ConnectedCard fully functional with We Connect ID.

But all other bindings where gone. I cannot re-install this binding (endless installation) nor other new bindings. OH3 bindings seems to be dead outside of ConnectedCar.

Nothing to see in the OH logfiles.

I'm using OH 3.2.0 on openhabian on Rasperry PI 4.

Hello Markus (& Co.?)

My family upgraded from a very old Apple Airport WiFi to a new more powerful ASUS router.

Ever since then we noticed however, that all shelly items that are battery powered are not updating their sensor data anymore.
For example the Shelly H&T sensors we have are only sending smth. when we press the button on them.
We changed places to hotter / colder regions, where the webpage of the shellys are showing new sensor data like higher temperatures.
OpenHab however, does not receive thoses changes.

The shelly configuration has stayed the same since the old WiFi.
When switching to the Apple WiFi, everything works, when going to the new ASUS router, no updates get through.

I went through all the settings I could find on the new router and did not find anything weird, especially since the rest of the OH things are working fine.
Only the battery-powered Shelly sensors stopped sending Updates.

I manually installed your 3.1.0-SNAPSHOT binding with the appropriate dependencies to test whether the dev version works: No luck.
The behaviour stays the same and I am quite a bit at a loss.

Thank you for your help.

https://www.shelly.com/en-fr/products/product-overview/shelly-gateway

From the upcoming firmware >=1.1.0 (currently still beta 3) on some Shelly Plus devices, the values ​​already recorded for the total energy consumption that are sent to Openhab are retained, e.g. when the voltage to the device is switched off or the device is restarted or the Device firmware is updated.

Furthermore, the device from FW>=1.1.0 Beta 3 supports resetting via the web interface energy consumption.

It would be great if the channel for resetting energy consumption could also be made available in Openhab?