autocreate not doing anything

Begonnen von tomaszG, 21 Dezember 2018, 09:52:25

Vorheriges Thema - Nächstes Thema

tomaszG

Hello ,

I have tried to disable autocreate by setting the attribute disable to 1 and after that I deleted the attribute so it is now showing that autocreate is active. However, it is not autocreating devices on the network and I don't understand why: I tried shutdown restart to no avail also.

Any idea what is the problem ?

T

Beta-User

Hi T,

seems you are talking about MQTT devices - as your only other post are MQTT related?

In case if: What TYPE is the IODev you defined? MQTT or MQTT2_CLIENT?

Do you have a lot of MQTT stuff to integrate or is just a few devices with moderate data volume to handle? In the later case, have a look at MQTT2_SERVER also (to replace MQTT/MQTT2_CLIENT and e.g. mosquitto).

In case of usage of an external broker like mentionned mosquitto, I'd recommend using MQTT2_CIENT as IODev (might be additional to MQTT in case you have already configured some MQTT_DEVICE's, MQTT_GENERIC_BRIDGE works with all the three IO-options, don't mind the commandref's restriction to MQTT).

Then autocreate has also to be configured at the MQTT2_CLIENT (or MQTT2_SERVER) side.

Hope, this helps a little?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

If Beta-Users advice wont help: please provide an "attr global verbose 5" log for the time interval where you think a device should have been autocreated, and a "list -r" of the device receiving the data (aka IODev).

tomaszG

Hello,

First, yes I am using MQTT but I have a network of EnoCean devices.
I think I was mistaken regarding the autocreation. It is only autocreating when I am in teach mode.

What is the main reason to use MQTT_CLIENT2 rather than the MQTT ? I am using Mosquitto as the broker.

While I am at it, I'll be deploying a large number of controllable EnOcean valves for a research project in the near future (400 of them !) and the plan is for now to pair them in small groups of 10 to 20 to a number of RPi computers embarking FHEM. there will be then one central node with the MQTT broker ans some other data management code. Any suggestions, limitations I should be aware of ?

Best

Beta-User

Hello T,
sounds like an interesting project!

Don't know EnOcean from practical side, but in general, splitting up the entire thing in segments sounds reasonable, and if you plan to have a central node with whatever software using info from your broker, using a dedicated broker imo makes sense.

Using MQTT2_CLIENT has imo 2 advantages: autocreate for MQTT-speaking-devices is possible, and authentification mechanisms are available (MQTT module lacks that afaik).
If I got you right, you are planing to just use MQTT@FHEM to bridge your EnOcean hardware to MQTT protocol, the later may be the remaining small advantage, with the disadvantage of MQTT_GENERAL_BRIDGE not been thouroughly testet for use with MQTT2_CLIENT; it's just some weeks this is part of FHEM (but no complaints so far).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

tomaszG

Hello,

We are having good progress on the project and MQTT2_CLIENT works well (including with MQTT_GENERIC_BRIDGE) ! I am now trying to enable the SSL for MQTT2_CLIENT but I could not find clear instructions on how to make it work correctly. I found a couple posts on the German part of the forum but no clear idea how to make it work.
I tried to add a valid certificate in a subfolder certs/ as decribed on the SSL for Web interface here https://wiki.fhem.de/wiki/Raspberry_Pi_%26_HTTPS but for the moment when I activate SSL attr of MQTT2_CLIENT, it does not connect and I don't know why. I also don't know if I can find a log of the connection attempts somewhere ?

Best

rudolfkoenig

The MQTT2_CLIENT module does not use certificates, you have to disable the checking of client-certificates on the server.

The document you linked in your input is relevant for Server-Type interfaces like telnet, FHEMWEB and MQTT2_SERVER. And I dont advise on setting the sslVersion attribute there, only if you have problems with the default.

tomaszG

Hi,

To recap, I have defined the following objects on a fhem client on raberry pis

define locmqtt MQTT2_CLIENT mywebsite.com:9883
attr locmqtt SSL 1

define mqttlog FileLog log/mqttlog-%Y-%W.log locmqtt

define mqttGeneric MQTT_GENERIC_BRIDGE mqtt subType=hvac.04
attr mqttGeneric IODev locmqtt
attr mqttGeneric globalDefaults base={"enocean/$device"}
attr mqttGeneric globalPublish *:topic={"$base/$reading"}


with a bunch of enocean devices that collect data and are supposed to post it on a server accessible from the web.
My questions are :
1) How do I know if something is happening (if he tries to connect, what happened, etc.) ? The FileLog does not seem to show anything.
2) do I need the ca certificate somewhere along the fhem client so that he can authenticate the server ? from what I understand he will not try to authenticate the server.

Best

Beta-User

Hi,

despite beeing not really familiar with MQTT_GENERAL_BRIDGE, globalPublish imo isn't really working as expected. Afaik, @hexenmeister added that feature more or less for testing purposes (and dislikes it now/does not support it anymore), so I'd suggest to do all kind of publishing configuration in your individual (EnOcean-)-Devices, not in the mqttGeneric-Device.

Additional remarks:
- Using code tags (the # button above the editing field) makes post easier to read.
- Perhaps you move your post to the MQTT part of the forum and edit the title.
- There's also a very instructive Thread started by hexenmeister explaining typical use cases for mqtt_general_bridge; if you are able to read at least some german, you might consider the code examples there to be very useful.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Zitat1) How do I know if something is happening (if he tries to connect, what happened, etc.) ? The FileLog does not seem to show anything.
Such stuff is logged to the FHEM-log (attr global logfile), which can also be monitored in the FHEMWEB Event-Monitor, by setting the appropriate flag in the UI. But the usual tail command on the unix console works best.
You have to set "attr locmqtt verbose 5" to see a lot of details.

Zitat2) do I need the ca certificate somewhere along the fhem client so that he can authenticate the server ?
As I wrote earlier: NO
BUT: you have to change the moquitto configuration, as per default it is expecting a client certificate.


tomaszG

Thanks for the help Rudolf. I was checking the fhem log, but I guess I was missing the attr locmqtt verbose 5. I'll check now.
Regarding SSL, I am not talking about a user certificate, which mosquitto does not require by default (see https://primalcortex.wordpress.com/2016/11/08/mqtt-mosquitto-broker-client-authentication-and-client-certificates/, require_certificate and allow_anonymous are false by default in Mosquitto). I am talking about the certification authority certificate that the client needs to be able to verify the legitimacy of the server (assuming it is not shipped with the client implementation, for example in the case of self-signed certificates). I am not an expert in SSL, but this is my understanding after digging into it in details.

Finally, regarding Beta-user comments on generic bridge, it has been working for me so far (with MQTT and MQTT2_CLIENT) and is immensely convenient because I am dealing with many devices that I don't know in advance. I actually received the suggestion to use MQTT_GENERIC_BRIDGE on another thread because automating the creation of the individual bridges with templates was not working for me.


rudolfkoenig

ZitatI am talking about the certification authority certificate that the client needs to be able to verify the legitimacy of the server
FHEM SSL clients do not check the legitimacy of the server by default, so there is no CA certificate necessary.
You can configure this for certain FHEM modules, but not (yet) for MQTT2_CLIENT.

tomaszG

Thanks,
I got it working in the meantime, as with the logs I had all the information in hand.

Best