hw_key

Plugins & Plugin Development openLuup
#1

Small change request here. I am using a plugin on openLuup that requires the vera hw_key as a seed value for some random number generation. I can see in the luup.lua file that ‘hw_key = “–hardware key–”’. However, I don’t see any other code that either pulls the key from a bridged vera, or generates a new key from the underlying openLuup hardware.

With this in mind, is it possible to enable the adding of this attribute to the attribute setup in start. Or failing that, perhaps generate the key in the same way that vera does. I believe it is stored in a text file on the vera. I am currently using a hacked version of the plugin that hard codes the key value (from my bridged vera), but would prefer not to do this in the event of a plugin update by whomever that would overwrite the hack…

#2

So interesting, I have been kind of hacking the vera to make that very key disappear as I don’t see it used anywhere besides the mios communications which I disabled. Did not know a plugin was written to make use of it. Could you import the key file into openLuup and just poll the key from there? There are actually 2 HW_keys and a PK_AccessPoint and a PKAccount files in the /etc/cmh/ folder of the vera.

#3
Could you import the key file into openLuup and just poll the key from there?

Yes, I could set the value directly in luup.lua, but the next iteration of openLuup would overwrite the hack. However, setting the attribute in startup would work, but I believe AK would need to initialize the variable a little differently in luup.lua to take this direction.

I’m basically trying to avoid scenarios where updated code overwrites any hacks I put in place–mainly because the passing years make it harder to remember where and what all my hacks are :slight_smile:

#4

It’s simply an unprotected variable in the luup table structure, so you can set it to anything you like in Lua Startup.

Because openLuup runs on any platform, there’s no universal way of attaching this to a hardware id.

The notion of cloning a bridged Vera’s id doesn’t work either, because there can be multiple bridged Veras (I have 3.)

#5

OK but ‘attr (“hw_key”, “1234656789AB564”)’ does not set the luup variable (at least the global that should be accessible from the plugin, and neither does luup.hw_key = “1234656789AB564”

How should this be done. I’d prefer to set the value using the attr method as it follows the convention for the similar PK_AccessPoint.

#6

AFAIK, [tt]hw_key[/tt] is not a system attribute.

This code (run on Vera) demonstrates that…

print(luup.attr_get "hw_key")
print(luup.hw_key)

So you can’t use luup.attr_set()

I tried [tt]luup.hw_key = “…”[/tt] (on openLuup) and that works fine. How does you plugin access that data?

#7

Here’s the code.

function GetGUID()
local crchash = “”
crchash = CRC32.Hash( tostring (luup.hw_key) )

return crchash

end

#8

The initial error was a nil error on hw_key variable, but it just may be a problem with the CRC32 module. I’ll take a closer look.

#9

It was the CRC32 module. It was not being called properly with the require statement. After hacking that bit of code, all is well now!!

I think I’m going to do a rewrite of this plugin as it appears abandoned (it’s a messaging plugin) and I want to add Email and as well as Telegram functionality. So it’s time to really start hacking the code…