Domoticz

kiddigital wrote: ↑Sunday 14 November 2021 8:34 Yes that is correct. And you should see in the logging a status message telling you that the aliasses file is found and used (or not).

And in this file tou can add “temperature_2” as an entry under ‘temp’.

Works! Thanks!

{
"temp": [
"temperature",
"ambient_temperature",
"temperature_2"
],

Hi @kiddigital,

I need some help as I got for the device below the log error message:
For device:
This is the current ttnmqtt_aliasses.json file:

{
"temp": [
"temperature",
"ambient_temperature",
"temperature_2"
],
"humidity": [
"hum",
"relative_humidity_7"
],
"baro": [
"barometer",
"barometric_pressure_6"
],
"batterylevel": [
"battery_level"
],
"gps": [
"gps_1"
],
"luminosity": [
"luminosity_5"
],

"accelerometer": [
"accelerometer_3"
],


"presense": [],
"analog_input": [
"analog_in_8",
"analog_in_4"
],

"analog_output": [],
"digital_output": [],
"digital_input": []
}

I think I need to add something additional for the 'accelerometer', what''s your advice?

Much appreciated,

Jeroen

@Jeroenkl , the group should be called ‘accel’ as that is the type that the module is looking for.

But it will give you a surprise

kiddigital wrote: ↑Sunday 28 November 2021 10:37 @Jeroenkl , the group should be called ‘accel’ as that is the type that the module is looking for.

But it will give you a surprise

@kiddigital,

I changed it:

2021-11-28 12:44:48.288 Error: TESTv3MQTT client gateway Wisblocks: Error parsing message (Type is not convertible to string)!!!

Same log message. Any advice as next step?

BR,

Jeroen

https://github.com/domoticz/domoticz/pull/5034

I'll test it as soon as the update is available.
Thanks Kiddigital!

I am playing around with Lorawan and TTN.

For that, I have ordered a Browan TBDW100 Door/Windows Sensor.

I have managed to include it to TTN and also have set up "The Things Network (MQTT/LPP)" in Domoticz.

When I trigger an event from the sensor, I receive " Error: TTN: Invalid data received! Unable to decode the raw payload and the decoded payload does not contain any (valid) data!"

I assume, I have to use a payload formatter in TTN or aliases in "ttnmqtt_aliasses.json" or something else?

This is the payload in TTN
Any help would be greatly appreciated!

Hi,

I realize this thread is old but as I'm trying to get data from an experimental device (LoRa E5 module) to Domoticz and run into the same problem as described here I thought it sensible to revive it.

The problem:
- My experimental device sends, via my own gateway, a CayenneLPP encoded payload: 0x01 0x67 0x01 0xFF.
- In the TTN dashboard I see this message come in and (using their payload formatter) it gets correctly decoded to "temperature_1": 51.1
- On my desktop using MQTT Explorer I am able to connect to the TTN MQTT server and also get the message, decoded correctly
- In Domoticz (Version: 2021.1, RPi) I added a new hardware device (The Things Network (MQTT/CayenneLPP) with LAN interface). In the logs I see that as soon as I create this device it connects to TTN:
2022-09-13 18:08:03.333 Status: myLoraDevices: Connecting to eu1.cloud.thethings.network:1883
2022-09-13 18:08:03.483 Status: myLoraDevices: Connected to: eu1.cloud.thethings.network:1883
2022-09-13 18:08:03.583 Status: myLoraDevices: Subscribed
(If I change the password to nonsense it fails to connect so I assume that the connection from Domoticz to TTN is OK)

- I added ttnmqtt_aliases.json to /home/pi/domoticz containing:

{
"temp":[
"temperature",
"temperature_1"
]
}

(I later added ttnmqtt_aliasses.json with the same content as I was a bit confused about what the correct name should be)
However, I do not see any indication in the log that Domoticz actually uses one of these files, which might explain why this does not work.

- The 'accept new hardware/sensors' setting in Domoticz is on.
- I tried the 'Allow for 5 Minutes' setting.
- But still Domoticz does not add a new sensor when I send a message through TTN.

What am I not seeing here?

Regards,

Paul

Looks you are doing it right way. The aliasses file (2 s’es indeed) should be in the domoticz home directory.

You should see either a Status message saying it found and processes it. Or an Error message that it could not process the file.

Are you using the latest release? Or otherwise try the Beta as I am not sure if the usage of the aliasses file is still in Beta and not yet part of the latest release.

No, I'm on 2021.1. Kind of reluctant to upgrade, for the RPi it runs on has not been upgraded for a while which could give me headaches when upgrading Domoticz.

But as the aliasses file might only be in the new version I'll have to bite the bullet

Thanks for you reaction!

After a Utilities-induced powercut last night Domoticz failed to autostart, so I grabbed that opportunity to upgrade the Pi and Domoticz (to V2022.1).

I see in the log that the aliasses file is used now. At first this gave me still no data from TNN, but, after I added an alias for 'humidity' in the json file things started to work!

I'm happy Thanks for the support!

Looking howto link TTN-sensordata to Domoticz-applications, preferably using Python3.x-scripting or PHP-scripting.

With LoraWAN for me still in the learning curve, try to read & understand this thread and it's brethern in this forum, but getting confused.
Not so much about the general examples, but what setup-details to be avoided (because 'old' for TTN_v2) and what is now required for TTN_v3/TNS3?

This description from TTN tells how the general setup should be for the functional chain from sensor to user.
Downto and including the TTN-server the path is clear enough, but for the next trajectory the critical aspect is:
"what is the quickest/shortest route to get data from TS3 into Domoticz, without borrowing auxiliary packages like PAHO-MQTT or Cayenne?"
Preferably a setup with just 1 Python3.x-script (or similar).
Any hints or ideas where to find such solution?

If I am correct you can get TTN devices directly into Domoticz with the TTN MQTT gateway. https://www.domoticz.com/wiki/TTNMQTT

As far as I understand not even a separate MQTT broker is needed.

Walter,

Before running-up to my question, I have read that section of the Wiki.
The reason for my question is exactly that under Introduction, line 5 and Configuration, line3 they mention CayenneLPP as requirement.
If I correctly understand, to get payload configured for Cayenne, specific settings have to be made at the source-side in the sensor-node and some requirements at the application-side:
to keep it simplest for a first setup, I would prefer to apply the 'native/raw' data-configuration from the sensor-node, and do all processing & translation behind the TTN-server at the application-side.

But no problem if somebody can simply/clearly explain why Cayenne-translation of the data in the sensor-node is the better idea.

The easiest way to use TTN is to package your data into the CayenneLPP format on the node side.

This way the TTN infrastructure takes care of a number of things and as an application you only have to subscribe yourself to the TTN MQTT broker(s) to receive nicely checked and decoded data (This is what the TTNMQTT modules does for you).

When the payload data is in CayenneLPP format the Domoticz TTNMQTT module automatically detects what type of data is in the payload an creates and manages the correct devices and types for you without the need for further configuration.

In this way, there is also no need for something like an ‘application’ that handles the payloads and then sends it forward to Domoticz.

This is by far the easiest way to use TTN and there are plenty examples and libraries for all kinds of nodes (arduino, wemos, etc).

If your node sends payload data in another (raw for example) format, you need to build a customer decoder somewhere in the chain to interpret the data.

You can do it in the TTN environment as there you have functionality to build and use customer decoders (javascript as far as I remember). The payload will get encoded by such a custom encoder before it is made available to the applications via the MQTT broker.

But then you still need a way to get the data into Domoticz. Can be done of course by using the API but that requires a custom module/application as well.

Lot of work for something that easily can be prevented by a few lines of code on the node.

Any reason NOT to use CayenneLPP on the node device? It is the way to keep things simple.

Convincing explanation.

Will try the best of both worlds:
- 1st phase = setup with just start & link of sensor-node (= Dragino type LSN50), aiming for 'raw' read-out at the TNN-Console,
proving that link can be made (also for testing that the 868MHz-communication-path is OK)
- 2nd phase = setup with Cayenne-settings in the sensor-node, trying to setup the functional chain from sensor to user-application
=> by your recommended setup in Domoticz
=> subsequent extraction from Domoticz for further application of the data.

For the TTN-interface probably needing a replacement for my Dragino Gateway LPS8,
in the catalogue see some alternatives which have MQTT-interface onboard, like Dragino LPS8N and Femto/Browan WLRGFM-100-EU868.
That almost looks like a shortcut-facility for data-transfer towards Domoticz, before involvement of the TTN-Servers in the dataflow.
Obviously the 'normal' functions can be run in/through the TTN-servers, but what might be best added value from this extra Gateway-facility?

Toulon7559 wrote:For the TTN-interface probably needing a replacement for my Dragino Gateway LPS8,
in the catalogue see some alternatives which have MQTT-interface onboard, like Dragino LPS8N and Femto/Browan WLRGFM-100-EU868.

What do you mean by ‘TTN-interface’? The TTNMQTT module connects over the internet directly with the TTN MQTT broker(s). No need for any gateway in between.

But for your IoT device(s), it might be needed to run a gateway of your own to provide network coverage for the devices in case no other gateways are in the vicinity to pick-up the signals of your device(s).

Toulon7559 wrote:That almost looks like a shortcut-facility towards Domoticz, before involvement of the TTN-Servers in the dataflow.
What might be best practise for application of such Gateway-function?

There is no short-cut possible as the devices are sending encrypted data which in only decrypted at the application level (application in the TTN network) so the gateway has no way of decrypting it.

The fact that the gateway uses MQTT to forward received packages from the gateway to the TTN environment is not something that can be leveraged by end-users/applications (as far as my knowledge goes).

In short: if your IoT device signals are pick-up by any gateway nearby, than there is no need to run a local gateway to get data into Domoticz.

TTN-interface = reading my EndDevice(s) via TTN_LoraWAN.
Effort trying to get connection to TTN since early 2019: see this message and later.
IF a Gateway would pickup the transmissions from my EndDevice(s),
THEN obvious that the TTNMQTT could do the job of datatransfer for Domoticz.
But then & now the TTN_maps show Gateways at considerable distance from my location, and no responses at the TTN_Console:
therefore conclusion to have to help myself with own, local Gateway connected to internet.
Reading docs and your message, then wondering what practical use for a MQTT-function in the Gateway (available at no additional financial cost),
besides the normal communicationchannel with TTN.

At this location coverage by KPN_LoraWAN is much better, but then don't see how to connect my EndDevices to Domoticz
[due to lack of knowledge and experience related to LoraWAN]

Toulon7559 wrote:TTN-interface =
…

At this location coverage by KPN_LoraWAN is much better, but then don't see how to connect my EndDevices to Domoticz
[due to lack of knowledge and experience related to LoraWAN]

So for TTN you are right, you need a local LoRaWAN gateway connected to the TTN network to make things work with TTN. You can use TTN without any costs.

If you want to receive the data via KPN than you need to get a subscription for your ‘app’ and maybe additionally depending on the amount of data.

Side-step & semi-offtopic, because not TTN-oriented, but closely related, offering a practical alternative.

The entry at KPN clearly oriented towards business applications, not towards private end users.
Pity, because their country-wide coverage is OK (and that is 1 hurdle less for an enduser in the Netherlands),
and as shown by example, an operational interface could be very friendly for endusers.
Perhaps an interesting challenge for one of the better technicians in this forum to make/describe a 'basic KPN-link for dummies' between e.g. a sensor Dragino type LHT65/LSN50 and Domoticz?
Why LHT65 and LSN50?
Both available in ready-to-go packaging, via multiple supply-channels and well-served with documentation
=> no DIY, except for setup of the link.
LHT65 has basic sensor-capabilities for Temp&Humidity in the device and an extra interface for a cabled DS18B20-sensor to measure temperature at some distance.
LSN50 is a 'universal' device with plenty of interface-options.