@TimO thanks for your time, but I am sorry to say there is another one:

Unresolved requirement: Import-Package: org.osgi.framework; version="[1.9.0,2.0.0)"

@monte said in Where did everyone go?:

I guess the main reason is that mysensors is very stand-alone framework. And it locked itself in purely hobbyist territory. So when there are vast amount of iot devices from various manufacturers that you can combine with your own diy solutions in zigbee-ikea-hue or esp-tasmota-mqtt ecosystem in mysesnsors you have to make all devices yourself if you want some kind of ecosystem, or rely on HA/openhab/nodered/domoticz with its script system to make something connected. Also strict requirement of arduino framework and outdated hardware as the core of the framework alienates the big chunk of iot developers out there. It feels like people come to mysensors, make relay node, temperature sensor and then go forward for more complex solutions to never come back.

well, yes, I agree, plus: in my experience some of the coders of mysensors are very (!!!) snobbish and autocratic. The idea behand mysensors is not that bad, but it got stuck - also ideologically - technically some years ago and there is no movement to be seen

@Chacha the log says it all: in OH3 the required package org.apache.commons.lang is installed with version 3.12.0

the (very depreciated) binding does only support up to version 3.0.0

the bug has been known for several months now.

there are 2 ways out of that situation:

a) if possible recode your sensors without mysensors and use Homie instead

b) get rid of the binding and use plain mqtt

this also applys to @syntacrsc

@syntacrsc well, for me it's no solution to throw Dollars into a pot that a community-based software get's some updates. either the software is state of the art ro it is not. and MySensors turned out to be not

@Chacha you are wrong: Homie is NOT ONLY for sensors.

@Chacha the log says it all: in OH3 the required package org.apache.commons.lang is installed with version 3.12.0

the (very depreciated) binding does only support up to version 3.0.0

the bug has been known for several months now.

there are 2 ways out of that situation:

a) if possible recode your sensors without mysensors and use Homie instead

b) get rid of the binding and use plain mqtt

this also applys to @syntacrsc

@oljo as I already mentioned: your posts are 100% off topic, because ypu do not use the OH3-binding for mysensors. you did some text-file thing-definitions with the MQTT-binding... apples and not plums

@tbowmo
what? it's a controller-part to decide which MQTT-dialect the gateway talks?

thanks for the words, now I know I am again treated as a fool

@tbowmo
uno runs maybe as serial ateway, but uno+ethshield+mqtt is not stable enough for a "productional"-environment. so the limitation is not UNO. some derivates with esp32/8266 will present enough horsepower to do that

finally: thank you for some openness ... we see where this leads to
there are some other project playing the converter/translator -role in the middle, but thats not so really cool, hence there needs to be node running...

@tbowmo
take my statemant as it is: my opinion, mixed with my experiences here in the forum. its a rather cheap argument, that btw. is always the second one that comes arround in discussions, to remind at the brave coders, doing all that in their freetime.
I did not say anything harsh in that direction. never.
nevertheless I agree with @NeverDie pointing out the big pro's of mysensors. but there has to be some limitation: all that only applies, when you want to rebuild some of the non-cloud systems with ONE (maybe in ver 3.0 two) physical layer. and the next limitation is the number of gateways that come into account when you want to scale things up (in a distance AND number of gateways point of view).
and if we get into alternatives, like homie, the advantages of mysensors decrease to a single point: radio.

referring to @NeverDie 's comment on the forum: its very hard to agree, because if you get your feature-request answered with "..pay somebody and you get what you want..." is not my definition of super-helpful, super-friendly

@tbowmo payload-length does not have anything to do with the node and the transport node-gateway, right?! we talk about gateway-mqtt and no other transport. and mqtt would even accept data of (at leaste) one jpg-image in ONE payload...

the same sketch on multiple devices (include the same mqtt-topics) sounds good, but will def. not work with eg. OpenHAB or MyController or whatever, because of the topic, and the fact, that nothing BEHIND the topic would make that node/sensor unique - i mean: there are enough ways to make a node unique...

the main "problem" is the need of a "binding" , the need of coding such a binding, the need of updateing that binding.....thats a lot of work to be done. and implementing a standard (and I call homie-convention a standard) will def. less work to do

@monte said in Where did everyone go?:

I guess the main reason is that mysensors is very stand-alone framework. And it locked itself in purely hobbyist territory. So when there are vast amount of iot devices from various manufacturers that you can combine with your own diy solutions in zigbee-ikea-hue or esp-tasmota-mqtt ecosystem in mysesnsors you have to make all devices yourself if you want some kind of ecosystem, or rely on HA/openhab/nodered/domoticz with its script system to make something connected. Also strict requirement of arduino framework and outdated hardware as the core of the framework alienates the big chunk of iot developers out there. It feels like people come to mysensors, make relay node, temperature sensor and then go forward for more complex solutions to never come back.

well, yes, I agree, plus: in my experience some of the coders of mysensors are very (!!!) snobbish and autocratic. The idea behand mysensors is not that bad, but it got stuck - also ideologically - technically some years ago and there is no movement to be seen

@tbowmo that would consume memory on the gateway, thats right, but that does not hurt, does it?
waiting for a working binding (eg. for OH3) or even writing something like a "binding" is - in my opinion- too much energy and, after several changes on the controller, not so extra sufficiant threads here I am almost as far as to recode all my (abt 120 sensors) to get rid of the need of a "binding".

my main point is NOT a "beautiful" mqtt-topic-space. its all about userfriendlyness.