Posts made by ronluna | Smart Home

ronluna

I was unable to get MQTT to work correctly in openluup... I had to give up... It's a real shame ... as ZwaveJS is by far the best thing I've seen to manage zwave networks.

ronluna

If there is something I can do to help, please let me know.

ronluna

I had to disable the MQTT Handler from the startup as it was crashing the entire engine.

ronluna

@akbooer with DEBUG enabled the logs show:

2022-03-20 15:54:54.501   openLuup.mqtt:: CONNECT tcp{client}: 0x55ae0e8b8318
2022-03-20 15:54:54.501   openLuup.mqtt:: ClientId: ZWAVE_GATEWAY-Zwavejs2Mqtt
2022-03-20 15:54:54.501   openLuup.mqtt:: WillTopic: zwave/_CLIENTS/ZWAVE_GATEWAY-Zwavejs2Mqtt/status
2022-03-20 15:54:54.501   openLuup.mqtt:: WillMessage: {"value":false}
2022-03-20 15:54:54.502   openLuup.mqtt:: UserName: ********
2022-03-20 15:54:54.502   openLuup.mqtt:: Password: ********
2022-03-20 15:54:54.502   openLuup.io.server:: MQTT:1829 connection closed  tcp{client}: 0x55ae0a5f7e78
2022-03-20 15:54:54.502   openLuup.mqtt:: RECEIVE ERROR: closed tcp{client}: 0x55ae0a5f7e78
2022-03-20 15:54:54.519   openLuup.server:: request completed (16415 bytes, 2 chunks, 1068 ms) tcp{client}: 0x55ae0c39f788
2022-03-20 15:54:54.587   openLuup.server:: error 'closed' sending 6 bytes to tcp{client}: 0x55ae0dfce198
2022-03-20 15:54:54.587   openLuup.server:: ...only 0 bytes sent
2022-03-20 15:54:54.587   openLuup.server:: error 'closed' sending 94946 bytes to tcp{client}: 0x55ae0dfce198
2022-03-20 15:54:54.587   openLuup.server:: ...only 0 bytes sent
2022-03-20 15:54:54.587   openLuup.server:: error 'closed' sending 2 bytes to tcp{client}: 0x55ae0dfce198

Seems like is related to what @toggledbits has shared a couple weeks ago. clues?

ronluna

I'm currently having a problem where the only way to get openluup to start processing messages from subscribed topics is by restarting the ZWaveJS service. When the ZWaveJS MQTT service is restarted the ZWaveJS Clients send the subscribe messages to openluup and only then is when messages start to get processed.

Testing with the following inserted in the startup:

local json = require "openLuup.json"

function MyMQTThandler (topic, message)
  local info = json.decode (message)
  local currentLevel = info.value
  luup.variable_set ("urn:upnp-org:serviceId:Dimming1", "LoadLevelStatus",  currentLevel, 68)
  luup.log("Processed")
end
 
luup.register_handler ("MyMQTThandler", "mqtt:zwave/Hallway_2/DImmer_1/38/0/currentValue")

I Couldn't find anything on ZWaveJS nor in openluup that might explain this behavior and my short mqtt knowledge is not helpful either.

Any ideas?

ronluna

Based out L_ShellyBridge.lua I've created initial L_ZWaveBridge.lua made changes in virtualfilesystem.lua to create D_ZWaveBridge.xml, D_ZWaveBridge.json and subcribed to zwave topic. which is how the MQTT messages are sent from ZWaveJS2MQTT by default.

my startup lua looks like:

luup.attr_set ("openLuup.MQTT.Username", "*********")
luup.attr_set ("openLuup.MQTT.Password", "*********")
luup.attr_set ("openLuup.MQTT.Port", 1811)
luup.attr_set ("openLuup.MQTT.PublishVariableUpdates", true)
luup.attr_set ("openLuup.MQTT.DEBUG", true)

With my short mqtt understanding ZWaveJS is connecting and authenticating just fine to openluup although I've been unable to properly modify L_ZWaveBridge.lua to capture and parse the messages that ZWaveJS is sending.

ronluna

Would be awesome to get ZWaveJS2Mqtt added to openluup. As much as ZWay has proven to be faster and much more reliable than Vera... ZWaveJS has a bright future...

ronluna

Maybe adding sockproxyd natively into openluup and modifying io.lua to optionally use sockproxyd could be a real winner to finally solve the limitations/problems in the I/O module.

ronluna

There is a little issue I'm currently facing with openluup and plugins that relies on io module.

If openluup is watching a variable that belongs to a devices that relies on io module and there is an action attached that also relies on io module, when that watcher gets triggered, the action in question will get processed in openluup (it will show in the logs) but the parent device won't process it.

I have a feeling that this could be due to io packets crossing between each others somehow modifying the final message received by the parent device. it's feels like the io communication is happening in the same room for all plugins and sometimes they get crossed. Wondering if anyone has experienced something of that sort and if there is a way to prevent it?

ronluna

@akbooer That's right... and just like that... apple is taking over then entire home automation industry.... too bad there is no Home app for Android. Well Front end and first layer voice control related...

ronluna

@akbooer get the latest copy directly from github at https://github.com/damianxd/homebridge-vera as npm is not current/synced with the github repo. In other words, install the plugin through the homebridge plugin section and then replace all the files located at "/usr/lib/node_modules/homebridge-vera/" with the latest on github.

ronluna

@a-lurker the second broadlink device in the network is indeed Mini split A/C that uses AC Freedom app. Both device are well within the wifi range and working fine when using their native apps so I doubt the timeout message has something to do with the strength of the connection. What I've noticed in the past when I've seen a timeout like this is due to the socket expecting a special carrier return <CR> or something in that sort, simply not understanding what was sent back to it.

I'm not familiar with the RM communication protocol... Although I'm all ears to see what else We could try to get this off the ground.

2021-04-03 14:20:18.155   openLuup.scheduler:: [82] BroadLink-Mk2 device startup
2021-04-03 14:20:18.155   luup_log:82: BroadLink_Mk2 debug: Initialising plugin: BroadLink_Mk2
2021-04-03 14:20:18.155   luup_log:82: BroadLink_Mk2 debug: Using: Lua 5.1
2021-04-03 14:20:18.155   luup_log:82: BroadLink_Mk2 debug: 0.57a --> PluginVersion
2021-04-03 14:20:18.155   luup.variable_set:: 82.urn:a-lurker-com:serviceId:BroadLink_Mk2_1.PluginVersion was: 0.57 now: 0.57a #hooks:0
2021-04-03 14:20:18.156   luup_log:82: BroadLink_Mk2 debug: Using: dkjson
2021-04-03 14:20:18.157   luup_log:82: BroadLink_Mk2 debug: Broadcasting discovery message
2021-04-03 14:20:18.157   luup_log:82: BroadLink_Mk2 debug: 10.1.11.22
2021-04-03 14:20:19.157   luup_log:82: BroadLink_Mk2 debug: Number of BroadLink devices found is 1
2021-04-03 14:20:19.158   luup_log:82: BroadLink_Mk2 debug: Header to be sent follows (ex checksum):

5A A5 AA 55 5A A5 AA 55  00 00 00 00 00 00 00 00   Z..UZ..U........
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 9B 64 65 00  00 00 8D DE 18 B0 43 A0   .....de.......C.
00 00 00 00 FB C8 00 00   ........

2021-04-03 14:20:19.158   luup_log:82: BroadLink_Mk2 debug: Payload to be sent follows (unencrypted):

00 00 00 00 A7 C5 DF 0A  91 33 F1 88 C9 82 A5 6D   .........3.....m
C8 BC F9 DF 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 01 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

2021-04-03 14:20:19.177   luup_log:82: BroadLink_Mk2 debug: Sending:  Authorisation: txMsg length = 136
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: RX of Authorisation msg response from 10.1.11.20 failed: timeout
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: This device is probably offline - mac address: a0:43:b0:18:de:8d
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: k = rf433
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: k = rf433 has no associated code at this time
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: k = ir
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d_ir
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: RM4 Pro - IR 1
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: urn:schemas-micasaverde-com:device:IrTransmitter:1
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: D_BroadLink_Mk2_IrRf_1.xml
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: type = function, value = function: 0x19a62d0
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: k = rf315
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: k = rf315 has no associated code at this time
2021-04-03 14:20:20.177   luup_log:82: BroadLink_Mk2 debug: {"a0:43:b0:18:de:8d":{"blInternalId":"00000001","blKey":"a7c5df0a9133f188c982a56dc8bcf9df","blDeviceType":25755,"blIp":"10.1.11.20","blDesc":"RM4 Pro"}} --> BroadLinkDevices
2021-04-03 14:20:20.177   luup.chdev.append:: [a0:43:b0:18:de:8d_ir] RM4 Pro - IR 1
2021-04-03 14:20:20.178   luup.chdev.sync:: [82] BroadLink-Mk2, syncing children
2021-04-03 14:20:20.178   luup.set_failure:: status = false
2021-04-03 14:20:20.178   luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: false now: false #hooks:0
2021-04-03 14:20:20.178   luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 1617440329 now: 1617474020 #hooks:0
2021-04-03 14:20:20.178   openLuup.scheduler:: [82] BroadLink-Mk2 device startup completed: status=true, msg=All OK, name=BroadLink_Mk2

ronluna

I tested the latest changes to add support for the RM4 Pro and it created a "IR" Child although it did not list any of the devices that have been created inside the RM4 Pro itself (Probably because is an RF device and that child was not created?). Also the IP set in the plugin attributes is different than the IP This is what the logs are showing:

2021-04-02 08:53:44.604   luup_log:82: BroadLink_Mk2 debug: The BroadLink device at IP address 10.1.11.126 and of type 0x4e2a is not known to this plugin

I do have another Broadlink device in the network so I guess is trying to discover that one as well.

2021-04-02 08:53:44.557   openLuup.scheduler:: [3] Alternate App Store device startup completed: status=true, msg=OK, name=AltAppStore
2021-04-02 08:53:44.557   openLuup.scheduler:: [82] BroadLink-Mk2 device startup
2021-04-02 08:53:44.557   luup_log:82: BroadLink_Mk2 debug: Initialising plugin: BroadLink_Mk2
2021-04-02 08:53:44.557   luup_log:82: BroadLink_Mk2 debug: Using: Lua 5.1
2021-04-02 08:53:44.557   luup_log:82: BroadLink_Mk2 debug: 0.57 --> PluginVersion
2021-04-02 08:53:44.558   luup_log:82: BroadLink_Mk2 debug: Using: dkjson
2021-04-02 08:53:44.559   luup_log:82: BroadLink_Mk2 debug: Broadcasting discovery message
2021-04-02 08:53:44.559   luup_log:82: BroadLink_Mk2 debug: 10.1.11.22
2021-04-02 08:53:44.603   luup_log:82: BroadLink_Mk2 debug: 10.1.11.126
2021-04-02 08:53:44.604   luup_log:82: BroadLink_Mk2 debug: Rx'ed a discovery response: rxMsg length = 128

5A A5 AA 55 5A A5 AA 55  00 00 00 00 00 00 00 00   Z..UZ..U........
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
E5 D6 00 00 2A 4E 07 00  00 00 DD 8A EB A7 DF 24   ....*N.........$
00 00 00 00 2A 4E 0A 01  0B 7E DD 8A EB A7 DF 24   ....*N...~.....$
E5 A5 A5 E5 85 8B E6 96  AF E7 A9 BA E8 B0 83 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 00 02 01   ................

2021-04-02 08:53:44.604   luup_log:82: BroadLink_Mk2 debug: Looks like the Cloud bit is set - that's not good
2021-04-02 08:53:44.604   luup_log:82: BroadLink_Mk2 debug: Friendly name: e5a5a5e5858be696afe7a9bae8b083
2021-04-02 08:53:44.604   luup_log:82: BroadLink_Mk2 debug: The BroadLink device at IP address 10.1.11.126 and of type 0x4e2a is not known to this plugin
2021-04-02 08:53:45.604   luup_log:82: BroadLink_Mk2 debug: Number of BroadLink devices found is 1
2021-04-02 08:53:45.604   luup_log:82: BroadLink_Mk2 debug: Header to be sent follows (ex checksum):

5A A5 AA 55 5A A5 AA 55  00 00 00 00 00 00 00 00   Z..UZ..U........
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 9B 64 65 00  00 00 8D DE 18 B0 43 A0   .....de.......C.
00 00 00 00 FB C8 00 00   ........

2021-04-02 08:53:45.605   luup_log:82: BroadLink_Mk2 debug: Payload to be sent follows (unencrypted):

00 00 00 00 A7 C5 DF 0A  91 33 F1 88 C9 82 A5 6D   .........3.....m
C8 BC F9 DF 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 01 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

2021-04-02 08:53:45.618   luup_log:82: BroadLink_Mk2 debug: Sending:  Authorisation: txMsg length = 136
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: Broadlink device: 649b replied with: 03e9
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: Error: errorMsg = fff9
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: This device is probably offline - mac address: a0:43:b0:18:de:8d
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: k = ir
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d_ir
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: a0:43:b0:18:de:8d
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: RM4 Pro - IR 1
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: urn:schemas-micasaverde-com:device:IrTransmitter:1
2021-04-02 08:53:45.632   luup_log:82: BroadLink_Mk2 debug: D_BroadLink_Mk2_IrRf_1.xml
2021-04-02 08:53:45.633   luup_log:82: BroadLink_Mk2 debug: type = function, value = function: 0x1a03140
2021-04-02 08:53:45.633   luup_log:82: BroadLink_Mk2 debug: {"a0:43:b0:18:de:8d":{"blInternalId":"00000001","blKey":"a7c5df0a9133f188c982a56dc8bcf9df","blDeviceType":25755,"blIp":"10.1.11.20","blDesc":"RM4 Pro"}} --> BroadLinkDevices
2021-04-02 08:53:45.633   luup.chdev.append:: [a0:43:b0:18:de:8d_ir] RM4 Pro - IR 1
2021-04-02 08:53:45.633   luup.chdev.sync:: [82] BroadLink-Mk2, syncing children
2021-04-02 08:53:45.633   luup.set_failure:: status = false
2021-04-02 08:53:45.633   luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: false now: false #hooks:0
2021-04-02 08:53:45.633   luup.variable_set:: 82.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 1617316371 now: 1617368025 #hooks:0
2021-04-02 08:53:45.633   openLuup.scheduler:: [82] BroadLink-Mk2 device startup completed: status=true, msg=All OK, name=BroadLink_Mk2

Any ideas how to get the RF portion working?

ronluna

@therealdb could use homebridge 2 openluup also...

ronluna

@Crille I was using an older version. I have pushed a fixed to make device's name persistent after engine reload. please update the plugin and share the results when you get a chance.

Thanks @akbooer for the pointing this out.

ronluna

@akbooer apparently on @Crille environment renaming plugin's children are not persistent after the engine reloads. although I can't replicate it on my end.

ronluna

@crille currently the plugin relies on an initial manual configuration and the current mechanism creates the children in a very dumb way. It is possible to build a more sophisticated interface although the plugin still in a "proof of concept state".

Yes, the devices are named DeviceType_UUID by default when they are created for the first time but after that I can rename them any way I want and the names remain persistent after engine reloads.

My understanding is that once a device is renamed on your setup it will get renamed back to the default deviceType_uuid after the engine reloads right? and that's what I can't replicate on my end.

ronluna

@crille said in Homebridge to Openluup:

luup.chdev.append

I'm really puzzled by this... Your logs looks just fine... The devices should not get renamed back when luup.chdev.append runs . if the devices where getting re-created the engine should be getting reloaded right away... What openluup version are you running?

Wondering if @akbooer sees something weird in how the plugin is syncing the devices after the append runs that could be causing it... at line 601 of L_Homebridge2openllup1.lua as it is something I'm not experiencing on my end... and I'm not sure where else to look...

ronluna

@crille I've been renaming renaming devices on my end without experiencing what you are describing. Are both Mitsubishi thermostat? Do you mind sharing an entire log output after an engine reload, additional 5 second log for the first device've value refresh and log output while rename a homebridge device from within openluup?

ronluna

@crille said in Homebridge to Openluup:

THERMOSTAT_uuid

That's odd... It shouldn't do that...

is your deviceList Variable ending with a semicolon ";" after your uuid ?

ronluna

Alexa for MSR, any interest?

openLuup console disappeared - 500 - Internal Server Error

Ezlo Paid Subscription for Vera Cloud Services

[RESOLVED] Telegram notification broke with latest update

[RESOLVED] Phantom device, “INFO” appears

[RESOLVED] Mode Status NULL

Reactor (Multi-System/Multi-Hub) Announcements

[RESOLVED] HTTP query failing after version 26177

Question about the find function

[Answered] OK to remove old json files?

Deprecation Announcement: 32-bit ARM docker images

[Solved] build 26150 - engine not starting

Farewell, oh good and faithful servant!

http request action & digest auth

Cloning actions in reactions does not work

Has ping command been removed?

ReferenceError with Home Assistant data & build 26140

Integrations and 'Loaded'

Possible mismatch between binary_sensor in HA and MSR

[Solved] Rulesets with multiple groups in Set Reaction not working post-26116

Posts