Author Topic: hw_key  (Read 224 times)

Offline Buxton

  • Full Member
  • ***
  • Posts: 203
  • Karma: +10/-0
hw_key
« on: January 12, 2019, 10:14:24 pm »
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.....

Online rafale77

  • Community Beta
  • Hero Member
  • ******
  • Posts: 1669
  • Karma: +90/-27
  • HA ≠ IoT as a blue sky is cloudless.
Re: hw_key
« Reply #1 on: January 12, 2019, 10:58:10 pm »
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.
openLuup (78 devices, 141 scenes, 19 apps) master to VeraPlus (142 zwave nodes, 8 Zigbee nodes, 221 devices,  20 scenes , 2 apps) +  Hubitat (15 Zigbee nodes) + Home-Assistant (API Integrations). Bridged to Siri and Alexa. Homewave. VeraPlus ExtRooted and mios server independent.

Offline Buxton

  • Full Member
  • ***
  • Posts: 203
  • Karma: +10/-0
Re: hw_key
« Reply #2 on: January 13, 2019, 03:22:13 am »
Quote
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 :)

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6341
  • Karma: +288/-70
  • "Less is more"
Re: hw_key
« Reply #3 on: January 13, 2019, 05:18:18 am »
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.)
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline Buxton

  • Full Member
  • ***
  • Posts: 203
  • Karma: +10/-0
Re: hw_key
« Reply #4 on: January 13, 2019, 05:04:53 pm »
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.

Offline akbooer

  • Moderator
  • Master Member
  • *****
  • Posts: 6341
  • Karma: +288/-70
  • "Less is more"
Re: hw_key
« Reply #5 on: January 13, 2019, 05:38:04 pm »
AFAIK, hw_key is not a system attribute.

This code (run on Vera) demonstrates that...
Code: [Select]
print(luup.attr_get "hw_key")
print(luup.hw_key)

So you can't use luup.attr_set()

I tried luup.hw_key = "...." (on openLuup) and that works fine.  How does you plugin access that data?
3x Vera Lite-UI5/Edge-UI7, 25x Fibaro, 23x TKB, 9x MiniMote, 2x NorthQ Power, 2x Netatmo, 1x Foscam FI9831P, 9x Philips Hue,
Razberry, MySensors Arduino, HomeWave, AltUI, AltHue, DataYours, Grafana, openLuup, ZWay, ZeroBrane Studio.

Offline Buxton

  • Full Member
  • ***
  • Posts: 203
  • Karma: +10/-0
Re: hw_key
« Reply #6 on: January 13, 2019, 06:21:49 pm »
Here's the code. 

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

    return crchash
end

Offline Buxton

  • Full Member
  • ***
  • Posts: 203
  • Karma: +10/-0
Re: hw_key
« Reply #7 on: January 13, 2019, 06:26:55 pm »
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.

Offline Buxton

  • Full Member
  • ***
  • Posts: 203
  • Karma: +10/-0
Re: hw_key
« Reply #8 on: January 14, 2019, 12:02:30 am »
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.....