ouch, thanks. at least we know why it’s not working. any idea which of different mqtt bindings I need to upgrade? like mqtt or mqtt.generic? and do you know if I will succeed by just updating the binding and staying at OH 2.4 stable? Or will I need to upgrade everything?
You don’t need to change the Things at all. You just need to upgrade the binding.
It will be way easier to upgrade your whole OH. 2.5 M1 was release a month after 2.4 Release. It’s very stable and I’ve been running on it since it was released with no problem.
OH is a rolling release. Honestly, there really isn’t any major difference between a milestone release and a release except the release has received just a tab more testing. But both are really just snapshots in time where there are no known show stopper bugs in OH core that get packaged up and frozen in place.
To just upgrade the binding you will need to uninstall it (and the broker add-on if you are using it too) then download the 2.5 M1 jar file and drop it into the addons folder. It will help to keep the console up and list the bundles to make sure the new binding is picked up and you don’t accidentally end up with both running at the same time.
1 Like
hey, me again. I updated to M1 and applied all your steps mentioned above.
When I was about to update my tutorial with your instructions, I noticed that the REGEX followed by JSON transformation doesn’t work as expected.
Actually the regex part is ignored and just the json part will be used. This way I have the same values (like IP address) assigned to all items. It’s exactly the other way round like with OH 2.4 where the regex worked, but json transform was ignored.
I re-installed the regex transformation add-on, but this didn’t solve the problem.
Actually even while the add-on WAS NOT installed, the json string was still transformed fine (but still ingoring the regex part).
Any idea what’s wrong?
things
Thing topic Shelly1-01 "Shelly1-01" { Channels: Type string : online "Online" [ stateTopic="shellies/shelly1-55521D/online" ] Type switch : applyfwupdate "ApplyFwUpdate" [ commandTopic="shellies/shelly1-55521D/command", on="update_fw", off=""] Type switch : power "Power" [ stateTopic="shellies/shelly1-55521D/relay/0", on="on", off="off", commandTopic="shellies/shelly1-55521D/relay/0/command", on="on", off="off"] Type switch : forceannounce "ForceAnnounce" [ commandTopic="shellies/shelly1-55521D/command", on="announce", off="announce" ] Type string : ip "Ip Address" [ stateTopic="shellies/announce", transformationPattern="REGEX:(.*shelly1-55521D.*)∩JSONPATH:$.ip" ] Type string : newfwflag "New FW Available" [ stateTopic="shellies/announce", transformationPattern="REGEX:(.*shelly1-55521D.*)∩JSONPATH:$.new_fw" ] } Thing topic Shelly2-01 "Shelly2-01" { Channels: Type string : online "Online" [ stateTopic="shellies/shellyswitch-5A4CE4/online" ] Type switch : applyfwupdate "ApplyFwUpdate" [ commandTopic="shellies/shellyswitch-5A4CE4/command", on="update_fw", off=""] Type switch : power1 "Power1" [ stateTopic="shellies/shellyswitch-5A4CE4/relay/0", on="on", off="off", commandTopic="shellies/shellyswitch-5A4CE4/relay/0/command", on="on", off="off"] Type switch : power2 "Power2" [ stateTopic="shellies/shellyswitch-5A4CE4/relay/1", on="on", off="off", commandTopic="shellies/shellyswitch-5A4CE4/relay/1/command", on="on", off="off"] Type switch : forceannounce "ForceAnnounce" [ commandTopic="shellies/shellyswitch-5A4CE4/command", on="announce", off="announce" ] Type string : ip "Ip Address" [ stateTopic="shellies/announce", transformationPattern="REGEX:(.*shellyswitch-5A4CE4.*)∩JSONPATH:$.ip" ] Type string : newfwflag "New FW Available" [ stateTopic="shellies/announce", transformationPattern="REGEX:(.*shellyswitch-5A4CE4.*)∩JSONPATH:$.new_fw" ] }
items
String Shellies_AnnounceData_String "Shellies AnnounceData" { channel="mqtt:topic:mosquitto:ShellyAnnounceData:announcedata" } Switch Shelly1_01_Switch "HomeOffice Licht[]" [ "Switchable" ] { channel="mqtt:topic:mosquitto:Shelly1-01:power" } String Shelly1_01_Online "Shelly1_01 Online [%s]" ( gShellyOnlineStatus ) { channel="mqtt:topic:mosquitto:Shelly1-01:online" } String Shelly1_01_NewFWFlag "Shelly1_01 New FW [%s]" ( gShellyNewFWFlag ) { channel="mqtt:topic:mosquitto:Shelly1-01:newfwflag" } Switch Shelly1_01_Ready2Update String Shelly1_01_IP "HomeOffice Licht IP [%s]" { channel="mqtt:topic:mosquitto:Shelly1-01:ip" } Switch Shelly1_01_ApplyFWUpdate "HomeOffice Licht FWUpdate" { channel="mqtt:topic:mosquitto:Shelly1-01:applyfwupdate", autoupdate="false"} Switch Shelly1_01_ForceAnnounce "HomeOffice Licht ForceAnnounce [%s]" (gShellyForceAnnounce) { channel="mqtt:topic:mosquitto:Shelly1-01:forceannounce" } Switch Shelly2_01_Switch1 "Shelly2_01 Power1" [ "Switchable" ] { channel="mqtt:topic:mosquitto:Shelly2-01:power1" } Switch Shelly2_01_Switch2 "Shelly2_01 Power2" [ "Switchable" ] { channel="mqtt:topic:mosquitto:Shelly2-01:power2" } String Shelly2_01_Online "Shelly2_01 Online [%s]" ( gShellyOnlineStatus ) { channel="mqtt:topic:mosquitto:Shelly2-01:online" } String Shelly2_01_NewFWFlag "Shelly2_01 New FW [%s]" ( gShellyNewFWFlag ) { channel="mqtt:topic:mosquitto:Shelly2-01:newfwflag" } Switch Shelly2_01_Ready2Update String Shelly2_01_IP "Shelly2_01 IP [%s]" { channel="mqtt:topic:mosquitto:Shelly2-01:ip" } Switch Shelly2_01_ApplyFWUpdate "Shelly2_01 FWUpdate" { channel="mqtt:topic:mosquitto:Shelly2-01:applyfwupdate", autoupdate="false"} Switch Shelly2_01_ForceAnnounce "Shelly2_01 ForceAnnounce [%s]" (gShellyForceAnnounce) { channel="mqtt:topic:mosquitto:Shelly2-01:forceannounce" }
then I manually publish a fake mqtt topic:
{“id”:“shelly1-55521D”,“mac”:“B6E62D55521D”,“ip”:“justfake”,“new_fw”:true, “fw_ver”:“20190214-074430/1.4.7-revertwifi@0f3372b3”}
log
2019-03-27 21:26:19.575 [vent.ItemStateChangedEvent] - Shellies_AnnounceData_String changed from {id:shelly1-55521D,mac:B6E62D55521D,ip:192.168.2.132,new_fw:true, fw_ver:20190214-074430/1.4.7-revertwifi@0f3372b3} to {id:shelly1-55521D,mac:B6E62D55521D,ip:justfake,new_fw:true, fw_ver:20190214-074430/1.4.7-revertwifi@0f3372b3} 2019-03-27 21:26:19.607 [vent.ItemStateChangedEvent] - Shelly1_01_IP changed from 192.168.2.132 to justfake 2019-03-27 21:26:19.613 [vent.ItemStateChangedEvent] - Shelly2_01_IP changed from 192.168.2.132 to justfake
Thanks in advance
I don’t use .things files for this so I can’t say if there is something wrong there. All I can say is it works for me. If you have both transforms installed and don’t see any errors in the logs I don’t see anything that looks wrong.
that’s indeed interesting. maybe it’s a bug? I re-created a Generic MQTT Thing via PaperUI, create an TestItem in PaperUI and then linked the item to the channel via PaperUI, same issue. If I enter something like “BLA” into the transformation field I do see an error in the log. But as soon as I turn this into REGEX:BLA it will be accepted and ignored.
Just in case something shows up as obvious, I wrote a tutorial on how I did this: MQTT 2.5 M1+ How to implement the equivalent to MQTT1 REGEX filters. That contains my current configuration.
1 Like
REGEX:bla should accept all incoming mqtt values that are exactly “bla”.
If you use regex first, you must make sure that a valid JSON is produced out of that transformation otherwise the jsonpath cannot work successfully.
thanks for trying to help. it’s driving me crazy. I’ve read your tutorial, but it seems all good to me. Here some screenshots:
and the log shows:
2019-03-29 10:03:11.299 [vent.ItemStateChangedEvent] - MQTTTestItem changed from UNDEF to this just doesn't make sense
Finally, if I change the transformation value from “REGEX:BLA” to just “BLA” I do see an expected error in the logs:
2019-03-29 10:33:24.572 [WARN ] [internal.handler.GenericThingHandler] - Channel configuration error java.lang.IllegalArgumentException: The transformation pattern must consist of the type and the pattern separated by a colon
But then again, as soon as I enter “BLA:BLA” the thing configuration will be accepted and the thing goes online. Again the transformation will just be ignored and the item gets assigned the full announce string.
So I’d say, either my installation is somehow corrupted, or it’s a bug.
Any idea how to generate debug logs for the transformation process?
Ah ok. So you are saying that there should be an error log if a transformation cannot be found instead of just passing the value on.
Please create an issue on GitHub to track this.
But wouldn’t that break this use case?
The use case (i.e. using REGEX to filter out messages published to a single topic so only certain ones get passed to the JSONPATH) depends on REGEX failing silently and passing the full message on if there is no match.
If the transform is malformed it does makes sense that there is an error.
I’m not sure I understand everything going on here.
no, this is not what I’m saying. my problem is that the transformation just does not work. I had set:
REGEX:bla
But the value that was assigned to the item is != bla
This must not be the case, right?
I don’t know if this was already suggested, but you could simplify the whole “command: announce” loop by sending the MQTT message to “shellies/command” with the payload “announce”. This will force all shellies on the MQTT server to send their announce message.
Only if the full message is literally “bla” would the regex match. But because you didn’t provide any parens the REGEX doesn’t actually return anything.
If you want “bla” assigned to the Item, like that your message needs to be just “bla” and the REGEX needs to be
REGEX:(bla)
If you want the Item to be assigned “bla” when any message that contains bla in it the REGEX would be
REGEX:.*(bla).*
If you want the Item to be assigned the full message for any message that contains bla the REGEX needs to be
REGEX:(.*bla.*)
The expression must match the full message. And you must provide parens to indicate the part of the message you want to pass on.
1 Like
You cannot imagine how thankful I am, but at the same time I’m really sorry because I don’t understand.
What I did:
REGEX:(bla)- MQTT message ‘foobar’ on topic ‘shellies/announce’
Second test with:
REGEX:.*(bla).*- MQTT message ‘foobar’ on topic ‘shellies/announce’
What I see in both cases:
MQTTTestItem changed from […] to foobar
It shouldn’t behave like this, right? I’d expect the item value either to be empty or unchanged.
But if you use “REGEX:something” then it doesn’t match “foobar” topic values anymore? Otherwise the regex transformation is not used at all.
That is the behavior I would have expected too.
I would have expected that if the REGEX doesn’t return anything that nothing happens, not that the full message get’s passed on bypassing REGEX. In my mind, a “nothing returned” result from the REGEX transform is a valid result of the transformation.
I could see ambiguity in how that empty value should be treated. Should that be an error and set the Item to UNDEF? Should that be itself passed on and set the Item to “”? Or should the message itself just become ignored?
Obviously, I would prefer the latter since it let’s us achieve the REGEX filter capability from MQTT1 which, unfortunately, is quite useful given how a number of providers decided it was a good idea to publish data from multiple devices to the same topic, like discussed above.
Of course this behavior also begs the question, how is it that when I put the REGEX in front of a JSONPATH it appears to work as I intend. If I use REGEX:(.*<shelly name>.*)∩JSONPATH:$.ip, only those messages that include <shelly name> appear to get passed to the JSONPATH and the rest of the messages that don’t include it get ignored.
no matter what I write after REGEX: the item will always change to foobar. even if I combine the regex with jsonpath
hey guys, some time has passed and I was forced to reinstall my whole OH instance. unfortunately I’m still facing the same issue. using the REGEX expression followed by the JSONPATH filter I’d like to assign the IP of a specific shelly device to a specific OH item. This does not work. Not sure if we were on the same page. Do you understand the problem? In any case, thanks in advance for your help.
Using OH 2.5 M1? Chaining doesn’t work in 2.4.
yep, 2.5M1
What I expect is:
If a specific shelly device name has been found in the announce message, then assign the IP address to a specific item. Unfortunately the first part (the device name) is ignored.