Posts made by Peter Loeffler

@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.

@oljo I am very sorry to ask, but how does your post connect to the topic of this thread?
....you are not using the mysensors-binding....

are there any plans/thoughts of implementing an optionall mqtt-transport that follows Homie-conventions?

activateable by (eg) #MY_GATEWAY_MQTT_HOMIE

@David-Dawson
great idea for that translation from homie to mysensors and back.

but I think it would be a better approach, if mysensors would have the ability to "speak" homie-convention in MQTT optionally (e.g. #MY_GATEWAY_MQTT_HOMIE)
that would eliminate the need of tweaking on an extra binding and let mysensors talk an IOT-standard

@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)"

@niccodemi
same problem here

Hello,

has anyone of you guys already a bibdign version for OH3?

referring to this post
https://github.com/tobof/openhab2-addons/pull/139#issuecomment-583279535

can please anybod conform, that the issues with the bining are solved ?
(and does discovery (finally) work ? )

regards
peter

well, I am sorry for the following, but:

if you want to messure soil-moisture, then using these sensors is a very bad idea.
maybe you could get arround with corrosion on the two electrodes by changing the polarity. but you will always meassure electric conductivity. and conductivity is extremely influenced by the presence of salt (not only NaCl ) and some of the nutrients are basically salt.

therefore I strongly recommend using capacitive soil moisture sensors
(e.g. this one https://robu.in/product/capacitive-soil-moisture-sensor-v2-0/ )

there is also a rather good video describing how and why that works.
Capacitive Soil Moisture Sensor V1.2 - Garden Test! – 10:59
— Gadget Reboot

if it's only to record humidity a capacitive soil moisture sensor could be an option.

@scalz so to be clear at the end: if THIS is the developer's sight of a "discussion" I am really out of it...

(and after all that I know, why people dont share the own developments on some point of the code, because of rude guys stopping "discussions")

so @admin : please close that topic

@scalz please don't get me wrong! I choosed MySensors because its a great framework!!! (and I thank every single programmer for his job)

....but:
why is there a "feature requests" section, when you tell me

a) write yourself whatever you want
b) take it as it is

as MANY others already asked in this forum, there is (not only me) a always re-appearing demand for enhanced hardware/tech. (eg IP)
so you would def. make several peoples happy, if we could use THE SAME MY_CONTROLLER_IP_ADDRESS and MY_PORT on a node-only, with the same transport that is used in the MY_GATEWAY_(tcp/ip-network)

@fotofieber said in Ethernet/WiFi-Client Gateway enhancement:

This could maybe solved by a new hal/transport/ip.

As the ESP32 can act as AccesPoint and WifiClient at the same time, he could be a gateway offering his service to nodes via his AccessPoint on a separate WLAN.

another solution could be:

add a defintion like MY_GATEWAY_ROUTING

#ifdef MY_GATEWAY_ROUTING
getId() ... at/of the interface of "MY_GATEWAY" and set it as "parent_id"
#endif

@mfalkvidd RS485=serial

as you mention that "multiple gateways" are then presented to the controller, that makes everything clear!!!

what would you name a device, that connects 2 physically different "networks" ...

....as long as this device DOES changes the data-packets (setting parent_id as the devices node_id in the higher network)? (for me this is a GATWEWAY)

....as long as this device DOES NOT change the data-packets? (for me this is a BRIDGE)

so there is to be resumed: MySensors can (out of the box) not buildup TREES
(thats a big big pitty)

@mfalkvidd
its not different, its the same....

maybe its my idea of a "gateway" that makes the problem

maybe you could follow me with this example:
lets say there is a gateway with MySensors and MY_GATEWAY_ETHERNET and MY_RS485.

The RS485 bus runs through some cooling-houses (they are farraday-cages). in every house there is a arduino-based MySensor MY_GATEWAY_RS485 and MY_RF** to collect the local sensors.

(I hope its that, what we both call a tree)

will this work?

@fotofieber
I am exactely at the same point!

using the MY_GATEWAY_* as a node is a big big issue, when you want to have a "higher" number of those. each of these devices has to be configured as a gateway in whatever controller you use.

following some other posts, the developers seem to have no view on ip-based sensors, and the word "gateway" is a little bit misleading.
the mysensors framework is a perfect framework for sensors though.

the AP-feature of ESP32 ESP8266 e.a. devices is, as you stated correctly, a perfect way to build a wifi-based backbone for such devices.

Some days ago I started to run exactely into this "problems" and as a easy to use "workarround" I tried the following:

I use a ESP* devices as an access-point and run a tenetserver on it. all the traffic is then bridged to one of the serial interfaces, which is (in my case) connected to a "mYsensor Ethernet gateway" , that uses a "fake" rs485 on its inside serial. those two serials are connect via crossed-over TX/RX lines. (see this sketch and activate the swap option)
https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/examples/WiFiTelnetToSerial/WiFiTelnetToSerial.ino

next "problem" are the ip-based client-nodes. I also expected that the "gateway" would register itself and all the nodes behind on the "outside" interface, but thats not implemented. SO the only way to gt that working is:
ESP*-IP-Client node (aka bridge):
Start wifi and connection to a AP.
Defina a Softserial device (with loopback)
Start a telnet-client(!!!) on the device and bridge all input/ouput to a that device.
Use MySensors framework (MY_RS485) and define the use of Softserial as the device (the same softserial as defined above).
THESE clients can now connect to

) an MySensors network either with conneting to a MY_ESP_GATEWAY or MY_ETHERNET_GATEWAY doe to the fact, that the IP-connection is nothing else but simple "serial over ip" if you want to name the child like that.

*) to a "bridge" like described above

maybe thats not teh nicest solution but a way to get serial transport over ip running.

CAVEATS:
*) "repeating nodes" could generate a denial-of-service by repeatedly re-transmitting the same packets
*) Wifi-AP and Wifi-Client on the same device is a bad idea: the Wifi itself is something like a hub (and definately not a switch in the ip-network-speaking), what means: you bring additional traffic to that hub (aka HF-channel) and screw down the performence

one more (future) thoughts:
maybe someone should try something like a "IP-Concentrator" or "Arduino based Controller" functionality. That means:
*) IP or mqtt-Gateway-functionality as already possible with mysensors
*) MySensor Gateways can connect to that devices via TCP. Incomming traffic needs to be "rewritten" for example NodeId of the connected GW needs to be altered into the last byte of the IP-address and vice versa

I am very sure that somebody already made this, but the difficulty is (as far as I see) the nameing of funtionality: GATEWAY vs. CONTROLLER vs. NODE vs.BRIDGE ...
The main argument against "a MySensor Sensor is always ONE Gateway" is, as you already stated, the amount of gateway-connections you have to maintain.

a last thought:
I have not played arround much with Nodemanager, but I think that "concentrator" functionality as well as "SerialOverIP" transport could maybe be easyly done there

cheers
Peter
(wenns zu unverständlich war, erklär ich das auch gern nochmal in deutsch)

EDIT: https://github.com/paulo-raca/ArduinoBufferedStreams/blob/master/examples/LoopbackBuffer/LoopbackBuffer.ino

@mfalkvidd not the gateways ar the "problem" - the nodes inside are (in a way). I thought that a gateway in client mode would act as one...

but what I dont get: @scalz says its a "tree-topology" how would you be able to make tree, if the gateways dont bundly their nodes and forward it to the uplink ?

-----anyway----
a feature lik "MY_SERIALoverIP" would be cool anyway...or a ethernet-gateway that is worth the name

@scalz

ok, maybe the sort version was not so easy to nderstand. I give the long version a try:
each of my big greenhouses will get the following quipment:
WemosMiniD1Pro --> MySensors ESP8266Gateway (Wifi of the "backbone") and MY_RS485 (reasons: external antenna connector, seperation of all the following from the "internet")

So Inside the greenhouse I could have 254 nodes comming from the RS485 side. that would make a cobweb of cables. So I decided to add a "wifi to serial bridge" aka esp8266 as WifI-AP (greenhouse-wifi), Telnetserver running on port 5003,sending everyting to serial1, where there is the mentioned Mini waiting.

when I now deploy 20 SoilMoisturesensors (in every greenhouse) I dont want to do a seperate code for each sensor eg to set topics etc.
they should connect to the telnetserver and act as nodes.
May Idea was to make them GATEWAY_ESP32 with clientmode. (what sounded to be a "client")

+*+
OpenHAB gets configured one mysensors-ethernetgateway per greenhouse and everything is done.

@scalz more simple? I don't agree!
for example:
I have like 20 equal sensors /4way soilmoisture per greenhouse (40mx8m) ... in 12 houses overall. they would all come with the same topic-id...so: no way!

what I have built so far: wifi-ap with a telnetserver on 5003 that is bridget to a serial interface connected to an esp8266 gateway. The Idea was, that the esp32-gateways connect to that port and get rs485 nodes there.

so I resume: i have to do the tcp-transport stuff myself, when I want simple nodes to connect via TCP...

@mfalkvidd I thought, that when a gateway is on client mode, it would connect to the controller, ask for a "outside_node_id" and present itself and the topology behind ...

UPDATE ... started with a completely empty example-sketch and ip-connection to the controller works, but: why is there no registration towards the controller?

@mfalkvidd sorry, my typo ... is did set MY_CONTROLLER_IP_ADDRESS

hi everyone

I have a bunch of ESP32DEVKIT modules lying arround and want to use them with wifi (please no discussion about the seperation of wifi and sensors...thats a wifi with only sensors, no IP connection to the inetrent is possible).

so following the istructions I thought I understand teh following:
if definde MY_GATEWAY_ESP32 and an IP-address in MY_CONTROLLER_IP let's the "gateway" act as a "client" and would connect to the "controller" via tcp/5003.

but fact is: there is no outgoing connect to the given p-address

did I get something wrong ?

cheers
peter