openweather plugin ?

[akbooer]

@ronluna said in Homebridge to Openluup:

Plugin files that resides in "cmh-ludl/" have a higher priority then "cmh-luld/files" right?

Here's the ground truth on search path order lifted straight from the openLuup file loader...

  local f = open "openLuup/"        -- 2016.06.18  look in openLuup/ (for AltAppStore)
    or open "./"                    -- current directory (cmh-ludl/) 
    or open "../cmh-lu/"            -- look in 'cmh-lu/' directory
    or open "files/"                -- 2016.06.09  also look in files/
    or open "www/"                  -- 2018.02.15  also look in www/
    or open ("built-in/", vfs)      -- 2019.05.29  also look in built-in/ for 'last chance' files

[Crille]

Yes, changing owner and updating files in cmh-ludl/ solved it all. It's working great now! Thank you @akbooer and @ronluna
Only issue now is renaming a device, the name is reset to THERMOSTAT_uuid on luup reload.

[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 ?

[Crille]

@ronluna I only mapped 2 devices with

T:uuid,uuid

also tried

T:uuid,uuid;

[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?

[Crille]

@ronluna Yes, both are provisioned by the same plugin and is of same physical model.

All those logs is too long to post or PM. My guess is that the luup.chdev.append overwrites the name.

2021-03-25 12:04:20.863   openLuup.scheduler:: [23] Homebridge2openLuup device startup
2021-03-25 12:04:20.863   luup_log:23: homebridge2openluup debug: luaStartUp running
2021-03-25 12:04:20.863   luup_log:23: homebridge2openluup debug: 0 --> Connected
2021-03-25 12:04:20.863   luup.variable_set:: 23.urn:ctrlable-com:serviceId:homebridge2openluup1.Connected was: 1 now: 0 #hooks:0
2021-03-25 12:04:20.863   luup_log:23: homebridge2openluup debug: 0.1 --> PluginVersion
2021-03-25 12:04:20.863   luup_log:23: homebridge2openluup debug: http://127.0.0.1:8581/ --> homebridgeURL
2021-03-25 12:04:20.863   luup_log:23: homebridge2openluup debug: DeviceList Values = T:bc2e86fa8031082fd9d44cd9baf66c5dfd56b96165eae2b7fc26f4314230bf7f,8f37721c51dc9fd6b15aad7024d6a8460038b1ee7e6fb23c732f1abc5bcfb8fd;
2021-03-25 12:04:20.863   luup.chdev.append:: [bc2e86fa8031082fd9d44cd9baf66c5dfd56b96165eae2b7fc26f4314230bf7f] THERMOSTAT_bc2e86fa8031082fd9d44cd9baf66c5dfd56b96165eae2b7fc26f4314230bf7f
2021-03-25 12:04:20.863   luup.chdev.append:: [8f37721c51dc9fd6b15aad7024d6a8460038b1ee7e6fb23c732f1abc5bcfb8fd] THERMOSTAT_8f37721c51dc9fd6b15aad7024d6a8460038b1ee7e6fb23c732f1abc5bcfb8fd
2021-03-25 12:04:20.863   luup.chdev.sync:: [23] Homebridge2openLuup, syncing children
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: URL request result: r = 1
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: URL request result: c = 201
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: URL request result: h = table: 0x55af4d7c10b0
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: response_body 1 = {"access_token":"XXXXX","token_type":"Bearer","expires_in":28800}
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: Returned web page data is : {"access_token":"XXXXX","token_type":"Bearer","expires_in":28800}
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: XXXXX --> access_token
2021-03-25 12:04:20.866   luup.variable_set:: 23.urn:ctrlable-com:serviceId:homebridge2openluup1.access_token was: XXXXX now: XXXXX #hooks:0
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: Bearer --> token_type
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: response_body_parse access_token = XXXXX
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: response_body_parse token_type = Bearer
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: response_body_parse expires_in = 28800
2021-03-25 12:04:20.866   luup_log:23: homebridge2openluup debug: 1 --> Connected

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

[Crille]

@ronluna I'm running the openLuup version from development branch 2021.03.25b
So your log says THERMOSTAT_uuid as well on the luup.chdev.append? If so I'm guessing wrong
Is there any possibility to set the name from homebridge since it's picking up serviceName in startup?

2021-03-26 13:47:13.306   luup_log:23: homebridge2openluup debug: homebridgeGetDevices91 = uniqueId bc2e86fa8031082fd9d44cd9baf66c5dfd56b96165eae2b7fc26f4314230bf7f Type : Thermostat serviceName : Källaren
2021-03-26 13:47:13.306   luup_log:23: homebridge2openluup debug: homebridgeGetDevices92 = uniqueId 8f37721c51dc9fd6b15aad7024d6a8460038b1ee7e6fb23c732f1abc5bcfb8fd Type : Thermostat serviceName : Övervåningen

Otherwise I can live with the default name, your great plugin is doing what I needed and is intended to operate in automations in the background for my implementation of it anyway.

[akbooer]

@ronluna said in Homebridge to Openluup:

Wondering if @akbooer sees something weird in how the plugin is syncing the devices

I've not been following this discussion (although I am about to install Homebridge in a Docker to give it a whirl.)

Can you briefly summarize the issue?

[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]

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

[akbooer]

What versions of openLuup are you both running?

[Crille]

I'm always running the latest from development waiting to begin with MQTT. I implemented a workaround for this issue by setting my custom names in Lua startup.

[akbooer]

@Crille, thanks.

@ronluna, if you're running an older system, then you may not have seen this change:

-- 2020.12.19  allow luup.chdev.append() to change device name (thanks @rigpapa)

This fixed an inconsistency with native Vera behaviour.

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

[Crille]

@ronluna Excellent work, the name is now persistent on reload, thank you!