Setting semantic class to Point or Measurement also doesn’t help. As a workaround I use the Shellys status page, HTTP Binding and a JSON transform to get the voltage which actually works fine.
Is anything useful in the logs? Can you try to create the item automatically directly from the channels page?
@markus7017 Many thanks for your help. I didn’t know the Shelly Manager. So I did it for all my 34 shellies one at a time. With the unicast mode thy are changing now the values (state, current watts) fast (1-2 seconds).
you made it👍
try the latest DEV build (3.3)
enable DEBUG log and check for an exception
If you added through main UI channels/Items must fill without any other config
I found a bug, please try the latest DEV build
Fixes/Features
- Support for Shelly TRV (not fully tested)
- Channel device#supplyVoltage re-added
- Event types BUTTON | PERIODIC | SENSOR will not be posted to the alarm trigger channel
- Categories to thing types and many channel types added (Metadata)
- serviceName will be used instead of deviceName to avoid duplictate devices in the Inbox after changing Device Name in the Shelly settings
- README updated
Please help testing and reviewing documentation. Nevertheless, keep the jar if you already have the DEV build installed in the addons folder. Deinstall the regular version before installing the DEV build.
3.3.0-DEV Build - README - Avdanced Users - Shelly Manager - Bugs/Features - Firmware Index - Firmware Archive - API Doc | Note: The DEV build is always newer than the version in the official Distro or the Milestone builds (SNAPSHOTs); check here for more info on first installation
Hi Markus,
sorry, I don’t get it.
I am on OH3.2 and all Californium bundles are on 2.0.0.
280 │ Active │ 80 │ 2.0.0 │ Californium (Cf) Core
281 │ Active │ 80 │ 2.0.0 │ Californium (Cf) Element Connector
282 │ Active │ 80 │ 2.0.0 │ Californium (Cf) OSGi
Is it still required to install “your” Californium .jar files when installing shelly dev binding?
I am going to include my TRV now into OH. Will provide some feedback soon.
Californium ist not there by default. It depends on the installed bindings, e.g. Tradfi has a reference to this. In this case you don’t need to install and you shouldn’t. It should work with
- deinstall the Shelly binding, which is included in 3.2 standard install
- enable DEBUG log for Shelly (OH console: log:set DEBUG org.openhab.binding.shelly)
- copy the Shelly jar to the addons folder
You need to delete and re-discover Shelly things. The channel/item links should be restored (try with one before deleting all). This is required to update the XML definitions, which are used to create the channels. Firmware on the Shelly would be up-to-date.
Hello markus7017, thanks for the DEV3.30 build where TRV is now included.
I will wait for the official release, otherwise I need to reinstall +35 Shelly’s…
But the question is, that I saw in you documentation, that if I send a new temperature to the TRV, it will be not wake up and accept the new temperature value?, is this really the case, when sending from OH3 via a rule to the TRV, that it will not notice the new setting?
Uff… what to do in this case?
BR
Jochen
Hi Jochen,
which part of the documentation are you referring to?
The statement “While the device is in low power mode (usual operation) it will not respond to discovery requests” means that if the TRV is in normal operation (low power mode), the binding will not detect it as a new device. Therefore the device must be restarted or the reset pin must be pressed shortly. Then the TRV is “visible” for 3 minutes and can be added in Openhab.
Thanks Irgor,
you are right. My fault. I was interpreting the Note: You might need to reboot the device to enable the discovery mode for 3 minutes(use the Web UI). As an alternativ you could press the reset button shortly (refer to the manual to locate the reset button). While the device is in low power mode (usual operation) it will not respond to discovery requests, as “control” request. Everything in the content seems to be related to the “scan” phase to get the TRV found. So, then let’s get ASAP the 3.3 OH release out, that the new TRV will be offical supported. Thanks in advanced.
Please keep in mind
- OH 3.3 final will not be release before end if the year
- After a PR has been created and merged (will take several weeks)
- You need delete and re-discover the devices anyways to participate from new features/channels. There is no upgrade of existing channel defintions
Hello,
I wonder if there is a way to limit a number of events in shelly device or the binding?
For instance shelly 1PM generates info about every slight change of power (I think its due to the voltage fluctuations in the supply network) as follows
2022-01-11 16:17:21.205 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GF_KichenHood_Watt' changed from 0.63 W to 0.62 W
2022-01-11 16:17:23.451 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'GF_KichenHood_Watt' changed from 0.62 W to 0.64 W
Is it possible to limit sending or receiving events only when a threshold is met, eg 1.00 W?
The way I do that is by using a JS transformation, filtering the decimals…
My code is for sure not the most elegant one, but it does what I wanted;-) And I probably have found this somewhere else but don’t remember where, so can’t give credit…
filterdecimals.JS
(function(i) {
var s = i.split(" ")[0];
// var w = parseInt(s.toString(),10);
var w = parseFloat(s.toString());
var entier = Math.round(w);
var entier2 = entier;
if (entier > 99) entier2 = (Math.round(entier/10))*10;
if (entier > 999) entier2 = (Math.round(entier/100))*100;
return (entier2 + " W");
})(input)```I had the same conern as you.
But if you delete a thing it will reappear with all channel links to items. You just have to take care about the label. Anyway, as Markus recommends, do a test with one thing.
I also changed for each single shelly its device name (the one which is accessible through its webserver) so that it is identical with the thing name (without the suffix which is added by the binding). This way you don’t have to take care about labelling during re-adding process.
I have 20 shellys and I think it was done in 20-30 minutes.
@markus7017 , for this reason it might make sense to add “change device name” to your shelly manager?
Binding for Shelly TRV works without problems on my side. Is there anything I can do to complete testing?
the problem is that a LED could have < 1W consumption. I had something in for filtering, but removed it, because different devices have different consumption and there is no good default (0,1W, 1W, 10W); same with temp
are Ou concerned about log entries or changes triggering you rule very often?
I am concerned about number of log entries. What about an option/ parameter to set up the level of filterring in the binding?
Thank you for pointing this direction. I have not used profiles can be worth to try
you could setup log filters (standard OH feature), check the RRADME (advanced)