Providing logs from my productive OH instance seems not sensible as there are over 40 Shelly things configured and I suppose the relevant log lines would be hard to filter out.
Therefore I have put up a temporary OH instance with just one Shelly button thing configured. After configuring a keep alive of 2s for the button, I could reproducably get SHORT_PRESSED events for the third button press - the first two presses are still missing.
After raising the keep alive time, I tried to reproduce the behaviour of my testing instance with my productive OH instance, but there the problem persisted
As even the testing instance gets the coap messages of all shellies, it logs a lot of sensitive information. I will therefore send you the logs from my testing instance by direct message, @markus7017 . If this still doesn’t help, I can also send you logs from my productive instance.
Hello,
Im currently deploying a new clean OpenHAB setup and im using some Shelly Plus 2 PM for covers.
I started with a clean OpenHAB Setup (3.4.2, via deb, ubuntu 22.04, openjdk11)
The Instance is clean (freshly deployed LXC Container, only the official shelly addon installed).
Now to my issue: having the shelly plus configured in Relay mode, everything is fine.
However as soon as i try to bind one in cover mode, it doesnt work.
It goes into error state every time.
(Both tested from a fresh new template VM).
In the OpenHAB Log, there a NPE
java.lang.NullPointerException: null
at org.openhab.binding.shelly.internal.api2.Shelly2ApiClient.updateRollerStatus(Shelly2ApiClient.java:363) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiClient.fillDeviceStatus(Shelly2ApiClient.java:183) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiRpc.getStatus(Shelly2ApiRpc.java:552) ~[?:?]
at org.openhab.binding.shelly.internal.api2.Shelly2ApiRpc.getDeviceProfile(Shelly2ApiRpc.java:261) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.initializeThing(ShellyBaseHandler.java:286) ~[?:?]
at org.openhab.binding.shelly.internal.handler.ShellyBaseHandler.lambda$0(ShellyBaseHandler.java:188) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
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) [?:?]
It seems like that some objects are missing in cover mode in the Status request
id 0
source "timeout"
state "stopped"
apower 0
voltage 229.6
current 0
pf 0
aenergy
total 4.188
temperature
tC 49.9
tF 121.9
pos_control true
current_pos 95
this is my return value of a getStatus on a shelly plus 2pm with newest firmware
Just as Headsup and maybe for the Infopage:
I found the issue.
I blocked NTP in my firewall for the shellys ( or didnt allow it initially)
Without a correct time, the timestamp in the shelly is NULL (when you request it over the system rpc)
and hence the shelly does not send the energy timestamp. (wich breaks things in blinds/cover mode with the binding)
With correctly configured NTP server, everything works with the official repository.
As long term solution, maybe a warning/information should be added in the addon’s documentation.
Or the other way would be to make the binding more fault tolerant, so it doesnt take minuteTS as mandatory ?
I finally found time to retry again and dependencies are fine. I think the problem was the order of removing the built-in bundle and replacing it with the new one was somewhat not fully correct.
I see the channels and tried this:
But neither switching gShelly3EM_reset nor shelly_reset_L1 did something to the totals.
2023-03-14 18:10:17.814 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'shelly_reset_L1' received command ON
2023-03-14 18:10:17.821 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'shelly_reset_L1' predicted to become ON
2023-03-14 18:10:17.827 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shelly_reset_L1' changed from OFF to ON
2023-03-14 18:11:51.901 [INFO ] [openhab.event.ItemCommandEvent ] - Item 'shelly_reset_L1' received command OFF
2023-03-14 18:11:51.907 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'shelly_reset_L1' predicted to become OFF
2023-03-14 18:11:51.912 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'shelly_reset_L1' changed from ON to OFF
And counters did not change (neither totalKWH nor returnedKWH.
I guess I need some debugging turned on to see what is happening? What to do?
Nevertheless, from experience in the last I could say the Shelly need at least initially a timestamp (after each power cycle). Sometimes I saw strange effects when time was not set (at least with the Gen1 models).
I made this, because there is a Plug-S, Plug-IT, Plug-UK and Plug-US. It doesn’t make sense to do copy&paste for those device types if in fact it’s always the same definition.
What are you looking specifically for? Usually you set those values once and then the LEDs follow the power/WiFi/switch operation. What do you want to achieve?
Where do I find the repository this is built from and the actual changes? I cannot test it as is, due to the other issue with the selectedProfile, but would need to cherry pick the change in order to test it.
I thought my question was quite explicit, but I will try again: I cannot use your jar-File, as the selectedProfile is broken since the last release. However I want to test the changes you did for exception handling. Is there a repository, where the actual commit for these changes can be found, so I can have a look and cherry pick them?
