Sorry if this has been covered before, just curious why triggers in openluup are not consistent..
I looked at a scene i’d created a while back via ALTUI using the Console view and noticed it didn’t show any Triggers, which was strange as it was my main front door event 🙂 . So I added the door tripped trigger again, but I’ve just noticed I now how two tiggers using this view.
25bfe00a-d63e-4dc1-a501-23e779c64379-image.png
In ALTUI it shows this.
AK. Was doing an openLuup install and the installer errored with:
openLuup_install 2019.02.15 @akbooer getting openLuup version tar file from GitHub branch master... un-zipping download files... getting dkjson.lua... lua5.1: openLuup_install.lua:45: GitHub download failed with code 500 stack traceback: [C]: in function 'assert' openLuup_install.lua:45: in main chunk [C]: ?The installer code was executing this URL:
http://dkolf.de/src/dkjson-lua.fsl/raw/dkjson.lua?name=16cbc26080996d9da827df42cb0844a25518eeb3Running it manually gives:
dkolf.de The script could not be run error-free. Please check your error log file for the exact error message. You can find this in the KIS under "Product Management > *YOUR PRODUCT* > *CONFYGUAR* > Logfiles". Further information can be found in our FAQ. The script could not be executed correctly. Please refer to your error log for details about this error. You find it in your KIS under item "Product Admin > *YOUR PRODUCT* > *CONFIGURE* > Logfiles". Further information can also be found in our FAQ.I'm thinking the dkjson code URL has been changed. On dkolf.de there is a download link:
http://dkolf.de/dkjson-lua/dkjson-2.8.luaand dkjson code also seems to be in GitHub (I presume this is the same code?):
https://github.com/LuaDist/dkjson/blob/master/dkjson.luaI'm don't know what dkolf.de looked like previously but I do see the dkjson code has been updated as of 2024-06-17. Hope this helps.
Oh - and by the way the dkjson.lua file seems to have been downloaded OK by the installer - error or no error, so go figure.
It’s been a while since I looked at openLuup as it had been running nicely and quietly in the background doing some basic tasks. With my VeraPlus looking like it’s finally succumbing to old age, I want to shift a number of the global module I have over to openLuup.
To do this, I have added the files (example would be xxpushover.lua to the cmh-ludl folder and the following to the startup
require “xxpushover”
The xxpushover.lua file itself starts with the following..
module("xxpushover", package.seeall)
And I always have a line in these files to allow me to check it’s been read in the start up related logs, which in this case it is..
The challenge I’m having is that when I try to call any of the functions within the module, it returns the following error..
"[string "ALTUI - LuaRunHandler"]:1: attempt to index global 'xxpushover' (a nil value)”
I’m no doubt missing something obvious, can anyone help me find out what it is ? Many thanks
Currently I have some Whisper files used by DataYours that been working well for ages and do what I want.
One of the files is called Watts_L1.d.wsp and uses this retention from "storage_schemas_conf" in openLuup file virtualfilesystem.lua:
[day] pattern = \.d$ retentions = 1m:1dInside the actual "Watts_L1.d.wsp" file is a header like so:
1, 86400, 0, 1 84, 60, 1440The 1, 86400 is one minute & one day (in minutes) as per the retention listed above. As a side issue I would like to know what the other header values mean ie what's the syntax here?
New challenge: I now have three Shelly variables named:
em1/0/act_power
em1/1/act_power
em1/2/act_power
with a device ID of "10006" and a SID of "shellypro3em"
And I would like to plot them using the Historian, just like I do with Watts_L1.d.wsp in DataYours. So I need a file in the history directory for the data. So I looked at doing this:
local whisper = require "openLuup.whisper" -- Syntax: history/0.deviceNumber.shortServiceId.variableName local filename = "history/0.10006.shellypro3em.em1/0/act_power.wsp" local archives = "1m:1d" whisper.create (filename,archives,0)Problem is that the variable names contains forward slashes, which are invalid filename characters. What to do?
Also should the retentions now be (to suit the latest openLuup software)?:
local archives = "1m:1d,10m:7d,1h:30d,3h:1y,1d:10y"Also "shellypro3em" is not a "shortServiceID" as per those listed in "servertables.lua". So can "shellypro3em" be used instead? ie can both short and long service IDs be used in the above call to whisper.create?
To try and minimized the frequency of writing to the SD card I want to move these log files to a RAM drive, like I already do with /var/log. Is there an 'official' way of doing this?
_John.
A list of openLuup releases including the latest developments…
master – stable, and infrequently updated, development – latest updates and bug fixes, testing – use only when advised!A long while ago (May, 2015) I wrote my 2000-th post on another forum: openLuup - running unmodified plugins on any machine.
Now rehosted at https://community.ezlo.com/t/openluup-running-unmodified-plugins-on-any-machine/187412
Here’s the gist of it:
...I want to work in a more open and stable [Vera] environment...
...All would be solved if Luup was open source and could be run on the plethora of cheap and reliable hardware available today. But it’s not. But we could get something like that effect if we engineered a sufficient subset of Luup to run on such a platform. Could it be done? What would we need?
1. UI
2. scheduler
3. web server
4. Luup compatible API
5. Device and Implementation xml file reader
6. Zwave bridge to Vera
7. runs most plugins without modification
What we wouldn’t need is UPnP.
What have we (nearly) got already?
We have, courtesy of @amg0, the most excellent AltUI: Alternate UI to UI7, and that, I think, is probably the hardest one to do in the above list. Items 2 - 5, and 7, I’ve prototyped, in pure Lua, and posted elsewhere: DataYours on Raspberry Pi, running selected plugins unmodified, including: DataYours, EventWatcher, Netatmo, RBLuaTest, altUI. See screenshot attached.Is it worth the effort? Probably not. Will I pursue this quest? Yes.
openLuup was the result.
Hoping you could tell us a bit about your experiences with ZWaveJS and MQTT.
Akbooer: it would be good if openLuup was added to the awesome mqtt resources list.
How to contribute is described here.
Looks like the GetSolarCoords() doesn't return the correct results. Right Ascension (RA) and
Declination (DEC) look OK. They presumably must be, as I have a light that goes on at sunset at the correct time for years.
Altitude and Azimuth look incorrect. They both have the hour angle in common, so I'm wondering if it's incorrect and hence the sidereal time. Should be able to convert the angle to hours and check it against this clock:
The formula used looks like Compute sidereal time on this page. Might be some mix up between JD2000 that has a 12 hour offset. Could also be some issue with the hour angle.
I'm assuming all Right Ascension (RA) and
Declination (DEC) are degrees plus & minus from north.
Likewise Altitude (ALT) and Azimuth (AZ) are in degrees?
Bit of caution: I haven't looked at this too closely, so may be barking up the wrong tree. It probably doesn't help living near Greenwich.
This site may also be helpful.
PS did you have a look at the link in my last PM?
Set up:
a) Many many many many kms from home: laptop connected to modem router. Router running wireguard client to create a virtual network.
b) Home: modem router running wireguard server. openLuup pi4 connect to router and also a PC and other stuff, etc.
The problem: When accessing charts, AltUI or the openLupp console the web pages are returned OK up to the point where they are truncated and therefore fail to display anything useful.
Note this all works fine over short distances eg around a major city (I tested it) but not seemingly at world wide distances. ie network delays seem to be the issue here? Windows TeamViewer works fine overy the exact same network/wireguard set up. That's how I was able to get the openLuup logs shown below.
Here is any example of openLuup trying to return a chart:
2023-09-04 21:31:20.463 openLuup.io.server:: HTTP:3480 connection from 10.0.0.2 tcp{client}: 0x55aed35038 2023-09-04 21:31:20.464 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=316885191&Timeout=60&MinimumDelay=1500&_=1692128389970 HTTP/1.1 tcp{client}: 0x55ae538348 2023-09-04 21:31:20.465 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=316885191&Timeout=60&MinimumDelay=1500&_=1692129024374 HTTP/1.1 tcp{client}: 0x55addbe1e8 2023-09-04 21:31:20.477 openLuup.server:: GET /data_request?id=lr_render&target={temp_first_floor.w,temp_ground_floor.w,temp_back_wall_of_office.w,temp_inside_roof.w,temp_jps_bedrm_north.w,temp_outside.w}&title=Temperatures&height=750&from=-y&yMin=0&yMax=40 HTTP/1.1 tcp{client}: 0x55aed35038 2023-09-04 21:31:20.478 luup_log:6: DataGraph: drawing mode: connected, draw nulls as: null 2023-09-04 21:31:20.502 luup_log:6: DataGraph: Whisper query: CPU = 23.122 mS for 2016 points 2023-09-04 21:31:20.532 luup_log:6: DataGraph: Whisper query: CPU = 22.952 mS for 2016 points 2023-09-04 21:31:20.561 luup_log:6: DataGraph: Whisper query: CPU = 22.738 mS for 2016 points 2023-09-04 21:31:20.575 luup_log:6: DataGraph: Whisper query: CPU = 9.547 mS for 2016 points 2023-09-04 21:31:20.587 luup_log:6: DataGraph: Whisper query: CPU = 9.569 mS for 2016 points 2023-09-04 21:31:20.598 luup_log:6: DataGraph: Whisper query: CPU = 9.299 mS for 2016 points 2023-09-04 21:31:20.654 luup_log:6: visualization: LineChart(2016x7) 196kB in 51mS 2023-09-04 21:31:20.655 luup_log:6: DataGraph: render: CPU = 51.219 mS for 6x2016=12096 points 2023-09-04 21:31:20.755 openLuup.server:: error 'socket.select() not ready to send tcp{client}: 0x55aed35038' sending 2 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:20.855 openLuup.server:: error 'socket.select() not ready to send tcp{client}: 0x55aed35038' sending 6 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.037 openLuup.server:: error 'socket.select() not ready to send tcp{client}: 0x55aed35038' sending 2 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.138 openLuup.server:: error 'socket.select() not ready to send tcp{client}: 0x55aed35038' sending 6 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.332 openLuup.server:: error 'socket.select() not ready to send tcp{client}: 0x55aed35038' sending 2 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.432 openLuup.server:: error 'socket.select() not ready to send tcp{client}: 0x55aed35038' sending 6 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.507 openLuup.server:: error 'closed' sending 196367 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.507 openLuup.server:: ...only 144000 bytes sent 2023-09-04 21:31:21.507 openLuup.server:: error 'closed' sending 2 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.507 openLuup.server:: ...only 0 bytes sent 2023-09-04 21:31:21.507 openLuup.server:: error 'closed' sending 5 bytes to tcp{client}: 0x55aed35038 2023-09-04 21:31:21.507 openLuup.server:: ...only 0 bytes sent 2023-09-04 21:31:21.507 openLuup.server:: request completed (196367 bytes, 10 chunks, 1030 ms) tcp{client}: 0x55aed35038 2023-09-04 21:31:21.517 openLuup.io.server:: HTTP:3480 connection closed openLuup.server.receive closed tcp{client}: 0x55aed35038 2023-09-04 21:31:22.824 openLuup.io.server:: HTTP:3480 connection from 10.0.0.2 tcp{client}: 0x55aea22c88Re: socket.select() not ready to send
Is there some sort of timeout I change; to see if this can make this work?
Note that openLuup is still running everything flawlessly for ages now, including the more recent addtions of ZigBee stuff. Much appreciated.
Hi @akbooer
Just bringing this over as suggested..
I’ve started to use the console view a lot more, mainly for it’s look and simplicity , but I noticed it does not do any live updates compared to ALTUI, you have to do a full browser reload. Is that by design, or is mine not working?
Also if I want to go strait to the console view, rather than into ALTUI, I recall seeing something abut altering that in the guide by for the life of me I can’t find it. Is it possible to do, if so how would I do that..
You suggested this was something you were looking at ? Also you said You don't need a "full browser reload", just click on the display menu item to refresh the screen. - what do you mean by `display menu?
Very minor issue: was messing about renaming a few rooms and ended up with a room being listed twice. One with the room's contents and the other with no room contents.
It simply turns out one room name had a trailing space. It is possible in both AltUI and the openLuup console to create a room name with a trailing space. Once having done so chaos then ensues, as the rooms are not necessarily treated as different and become difficult to manipulate.
Just need to trim white space off room names. Haven't tested if it's possible to add in leading spaces. That may also be possible.
Hey guys...
Long time... 😉
Since my first day with Vera, I'm using RulesEngine from @vosmont to handle complex rules that will do something based on multiple condition base on "true/false" and also based on time.
Do you think I will be able to do that directly with LUA in openLuup ?
For example..
IF bedroom-motion1 is not detecting motion for 15 minutes
AND
IF bedroom-motion2 is not detecting motion for 15 minutes
AND
IF current-time is between 6am and 11pm
AND
IF binary-light1 is OFF
AND
IF binary-light2 is OFF
THEN
execute LUA code
WAIT 2 minute
execute LUA code
BUT IF any "conditions" failed while in the "THEN" , It need to stop...
I currently have around 60 rules like that 😞
Currently I have a Vera and Hue hub all reliably controlled by openLuup with AltUI, plus any number of plugins. Been working really well for a few years now. However would like to head for a more MQTT based set up. Eliminate the Hue hub and hopefully eliminate Vera by using ZWAVE JS UI. Noting that Zwavejs2mqtt has been renamed to Z-Wave JS UI. Probably also run the stuff using Docker. Just because. Everything would end up on the one computer for easier management. Erhhh that's the hope.
Some of the new Zigbee Aqara stuff is very good and inexpensive plus it fits in with HomeKit. Also the Aqara battery powered stuff looks to have a good battery lifetime: ie suggested up to five years. The battery operated Hue buttons I have; have lasted for ages. Would like to use zigbee2mqtt with a SonOff dongle, which would allow access to the over two and half thousand devices zigbee2mqtt now supports:
Zigbee2MQTTAK has the MQTT stuff working in openLuup. Have played around with it and it works well, as one would expect. Love the UDP to MQTT code.
Shellys are great and also very inexpensive and they spit out & accept MQTT but I would prefer to stay away from WiFi. Not meshed and higher power consumption. Horses for courses.
Now here's the query:
Got about forty or more ZWave twin light switches, plus a few other ZWave bits & pieces such as blind controllers. Then there are the Hue devices on top of that. That's a lot of virtual devices to set up in openLuup. What's an appropriate way to do this?
It seems there is no "auto magic bridge set up". Do I need to use say @therealdb's Virtual Devices plugin that supports MQTT or is there some other approach?
I have to confess I still don't understand the master child approach in that plugin. Seems one light switch would have all the other light switches hanging off it? Helps Vera but not a problem with openLuup - why is that? Suspect AK's good coding beats Vera's?
GitHub - dbochicchio/vera-VirtualDevices: Virtual HTTP Devices plug-in for Vera and openLuup GitHub - dbochicchio/vera-VirtualDevices: Virtual HTTP Devices plug-in for Vera and openLuupVirtual HTTP Devices plug-in for Vera and openLuup - dbochicchio/vera-VirtualDevices
Setting up manually say 100 virtual devices is a bit much to ask. I had a look at hacking the user_data.json file. Good approach till you see all the UIDs and the individually numbered ControlURL and EventURLs that need to be set up.
I need some way of say of creating about 80 light switches in "No room" or in say the "ZWave upgrade" room. Or say some sort of code that could go through all my existing bridged ZWAVE devices in openLuup and create virtual devices for each one. I caould then use the openLuup console to name them and place them in their rooms:
openLuup_IP_address:3480/console?page=devices_table
At that point I could hack the user_data.json file to insert the MQTT topics fairly easily for each? Plus any other fine tuning needed.
Then the old ZWave stuff could be swapped over to ZWAVE JS UI and all the virtual MQTT devices would be ready to go or am I dreaming? Then delete all the old Vera bridged stuff. I'm not too fussed about scene code and the like, as a I have all my code in one block, that is set up in the openLuup start up.
It seems that with ZWay you can create all the ZWave device by doing some sort of interrogation of ZWay's API? Seems also to be the case with the Shelleys?
So any ideas, suggestions or code snippets are welcome on how to move towards MQTT and in particular ZWAVE JS UI and zigbee2mqtt.
I'm in no hurry as openLuup is performing nicely, with the old Vera handling all my ZWave devices.
Hi
Just wondering if it’s possible when writing plugins to set if the text shown via DisplayLine1/2 can be left, right or centre aligned ?
Bit of an odd one this:
Bare metal install on Debian Bullseye (Intel NUC)
I've noticed when travelling, I connect to my L2TP VPN and I cannot get AltUI to update. I just get 'Waiting Initial Data'
Specifically this is in Chrome:
Version 108.0.5359.94 (Official Build) (x86_64)
In Chrome I can access and control everything via the Openluup console.
In Chrome I can also access and control everything via the Z-Wave expert UI and Z-Wave UI
In Safari I get a more complete view of AltUI but loads of errors along the lines of:
the module or function ALTUI_PluginDisplays.drawBinaryLight does not exist, check your configuration
Homewave on my iOS devices is fine across the same VPN config,
I can ssh into all my servers
Not a huge issue, just curious if anyone has any thoughts of what I might tweak to resolve it?
(FWIW I also access my IMAP and SMTP servers across the same VPN with no issues, as well as remote desktop. Also MS Reactor on the same host as Openluup)
TIA for any thoughts
C
Hi Ak,
Not sure when it started as it took me a while to notice.
I have a function on a luup.call_timer to turn on a switch and then use a luup.call_delay to turn it off a minute later. This is done by the same global function, but on the luup.call_delay i get a message in the log : "luup.call_delay:: unknown global function name: HouseDevice1_PumpCommand"
This is in the init function:
luup.call_timer("HouseDevice1_PumpCommand", 2, "2:15:00", hm_Heating.PumpHealthRunDay, hm_Heating.PumpCMD.HEALTH.."1", true)This is in the function to schedule to off command giving the global function name not found:
luup.call_delay("HouseDevice1_PumpCommand", hm_Heating.PumpHealthOnDuration, hm_Heating.PumpCMD.HEALTH.."0")Is it because I use the "TRUE" parameter that is openLuup specific so the timer does not fire just once?
Running v21.7.25, may be time to update?
Cheers Rene
Hi, I have been trying to install OpenLuup on MacOS but I am failing, so far.
Is there a step-by-step instruction (for MacOS) to follow?
After installing LuaRocks, luasec, luafilesystem and luasocket I then try to run lua5.1 openLuup_install.lua and then get the messages below.
Any ideas and proposals are appreciated.
Regards
Jan
openLuup_install 2019.02.15 @akbooer
lua5.1: openLuup_install.lua:18: module ‘socket.http’ not found:
no field package.preload[‘socket.http’]
no file ‘./socket/http.lua’
no file ‘/usr/local/share/lua/5.1/socket/http.lua’
no file ‘/usr/local/share/lua/5.1/socket/http/init.lua’
no file ‘/usr/local/lib/lua/5.1/socket/http.lua’
no file ‘/usr/local/lib/lua/5.1/socket/http/init.lua’
no file ‘./socket/http.so’
no file ‘/usr/local/lib/lua/5.1/socket/http.so’
no file ‘/usr/local/lib/lua/5.1/loadall.so’
no file ‘./socket.so’
no file ‘/usr/local/lib/lua/5.1/socket.so’
no file ‘/usr/local/lib/lua/5.1/loadall.so’
stack traceback:
[C]: in function ‘require’
openLuup_install.lua:18: in main chunk
Migrating Zwave & ZigBee stuff to MQTT - guidance needed.
-
-
There is a new version (v22.11.27) in the testing branch.
If you connect to the openLuup MQTT server, then it should detect the "bridge/devices" message and create some generic devices with some partial info about them in some variables. Just a basic test to show that the fundamentals work.
When the message is first detected, openLuup will create a Zigbee2MQTT bridge, a room called Zigbee and the child devices in that room. Here's what I get with the sample code you provided above (excellent starting info, by the way!) ...
-
@a-lurker said in Migrating Zwave & ZigBee stuff to MQTT - guidance needed.:
OK it works with them all set to skip although the documentation says blank, skip or http:// is OK . Might be useful to initialize them to skip.
Yep, time to update docs and the lib. Thanks for letting me know.
-
All works as advertised!! Excellent work. I still don't see the last image of the variables - still see the table pointers; as per your early image. Probably the latest code hadn't been committed to GitHub, judging by your commit times & post times.
I installed the openLuup testing branch and restarted. All worked as normal. Then I restarted the zigbee2mqtt server forcing it to output the "bridge/devices" message and everything got going in openLuup - great.
This is going to provide a lot possibilities. Currently 2507 possibilities! Downside is I may have to go and buy a few more devices.
Here's the start up log with a few edits and minus the date time. Might be useful to have say "none" or "****" for UserName & Password in the log. The "My Lua ver 0.50 debug:" is some of my test code:
Thank you very much for your efforts.
openLuup.io.server:: MQTT:1883 connection from XXX.XX.XX.XX tcp{client}: 0x47e20b0 openLuup.mqtt:: CONNECT tcp{client}: 0x47e20b0 openLuup.mqtt:: ClientId: mqttjs_19f169d2 openLuup.mqtt:: WillTopic: zigbee2mqtt/bridge/state openLuup.mqtt:: WillMessage: {"state":"offline"} openLuup.mqtt:: UserName: **** openLuup.mqtt:: Password: **** openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup.zigbee2mqtt:0: Topic ignored : zigbee2mqtt/bridge/state openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x47e20b0 openLuup.mqtt:: Packet Id: 0x2972 openLuup.mqtt:: Topic: zigbee2mqtt/# openLuup.mqtt:: mqttjs_19f169d2 SUBSCRIBE to zigbee2mqtt/# tcp{client}: 0x47e20b0 openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup.zigbee2mqtt:0: Topic ignored : zigbee2mqtt/bridge/info openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup.zigbee2mqtt:0: New Zigbee detected: 0x84b4dbfffecc0c6f openLuup.luup:: creating room [36] Zigbee luup.create_device:: [20001] D_GenericZigbeeDevice.xml / / D_GenericZigbeeDevice.json (GenericZigbeeDevice) luup.zigbee2mqtt:0: New Zigbee detected: 0x01234567890abcde luup.create_device:: [20002] D_GenericZigbeeDevice.xml / / D_GenericZigbeeDevice.json (GenericZigbeeDevice) openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup.zigbee2mqtt:0: Topic ignored : zigbee2mqtt/bridge/groups openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup.zigbee2mqtt:0: Topic ignored : zigbee2mqtt/bridge/extensions openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup.zigbee2mqtt:0: Topic ignored : zigbee2mqtt/bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup.zigbee2mqtt:0: Topic ignored : zigbee2mqtt/bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x47e20b0 luup_log:0: My Lua ver 0.50 debug: topic = zigbee2mqtt/0x01234567890abcde luup_log:0: My Lua ver 0.50 debug: device_temperature = 18 luup_log:0: My Lua ver 0.50 debug: illuminance = 316 luup_log:0: My Lua ver 0.50 debug: occupancy = false
-
Device detection would be good. Hoping to see but asking a lot:
- Occupancy sensor as per the device already shown in zigbee2mqtt/bridge payload.
- RGB & white adjustable light bulb in this link. It's pretty typical. RGB would be optional. ie some bulbs being white only tunable.
- Something like this Chinese dual outlet.. This would produce two virtual switches.
- Hue switch/buttons. and similarly something like this single button. or this one.
The above should allow a Hue hub replacement in most cases? Noting the Hue switch is pretty tricky to replicate. Seems like it's effectively a scene controller.
The Occupancy sensor also has illuminance and temperature but certainly at this stage; just need the device's primary function.
I note in the documents some of the properties are in round brackets eg:
light (state, brightness, color_temp, color_xy), effect, power_on_behavior, linkquality
I don't know but I suspect that those properties in round braces are sub properties of the property of 'light" and that would be reflected in the MQTT device definition json as such. I need to add in a few more devices to my zigbee network to be definitive.
I had a look at the ZWave JS UI . Probably not overly different form Zigbee.
-
@a-lurker said in Migrating Zwave & ZigBee stuff to MQTT - guidance needed.:
0x01234567890abcde is the "ieee_address" of the device and it can be associated with a "friendly_name" of your own choice, such as "bedroom1/left_corner/motion"
This would seem to be a somewhat ambiguous convention, since MQTT topics are also subdivided with the '/' symbol. Especially since these can then be suffixed...
- zigbee2mqtt/FRIENDLY_NAME/availability
- zigbee2mqtt/FRIENDLY_NAME/set
- zigbee2mqtt/FRIENDLY_NAME/get
...and so on.
I suppose we have to go with it.
-
New testing version v22.11.28 with the updated variable listing and also (perhaps) device identification for:
- lights (displayed as switch)
- switches (displayed as scene controller)
- occupancy (displayed as motion sensor)
- generic
The identified devices should have some of their standard serviceIds and variables.
Can I get a more complete bridge/devices JSON to try?
-
@akbooer
This is all coming along nicely - thanks.I've set up a Hue color/tuneable white light bulb as it's probably the most complicated of the lights. This is what it replies with when you do a "zigbee2mqtt/0xaa55aa55aa55aa55/set" with payload {"state": "TOGGLE"}
{ "color_mode": "xy", "linkquality": 255, "state": "ON" }
Not sure if the "color_mode" is actually changeable. ie whether it's always XY color (CIE 1931 color space) or whether it can be RGB style. I note the Ikea bulbs just seem to be XY space.
If I change a color in the zigbee2MQTT web page it sends (not sure about all the back slashes):
'zigbee2mqtt/0xaa55aa55aa55aa55', payload '{\"color\":{\"x\":0.4339,\"y\":0.5008},\"color_mode\":\"xy\",\"linkquality\":255,\"state\":\"ON\"}'"}
this is the reply from the bulb.
{ "color": { "x": 0.6942, "y": 0.2963 }, "color_mode": "xy", "linkquality": 255, "state": "ON" }
Here's "zigbee2mqtt/bridge/devices" for the light bulb only. You see there is a further lower level "features" below "exposes" ie "description,exposes,features". I've just cut & pasted the light bulb json description part below. It's just concatenated with the coordinator and the occupancy sensor, that you have already been using. I hope this is not getting unduly complex.
The coordinator and the occupancy sensor are listed here in the json and this is the light bulb: ... ,{ "date_code": "20210331", "definition": { "description": "Hue white and color ambiance E26/E27/E14", "exposes": [ { "features": [ { "access": 7, "description": "On/off state of this light", "name": "state", "property": "state", "type": "binary", "value_off": "OFF", "value_on": "ON", "value_toggle": "TOGGLE" }, { "access": 7, "description": "Brightness of this light", "name": "brightness", "property": "brightness", "type": "numeric", "value_max": 254, "value_min": 0 }, { "access": 7, "description": "Color temperature of this light", "name": "color_temp", "presets": [ { "description": "Coolest temperature supported", "name": "coolest", "value": 153 }, { "description": "Cool temperature (250 mireds / 4000 Kelvin)", "name": "cool", "value": 250 }, { "description": "Neutral temperature (370 mireds / 2700 Kelvin)", "name": "neutral", "value": 370 }, { "description": "Warm temperature (454 mireds / 2200 Kelvin)", "name": "warm", "value": 454 }, { "description": "Warmest temperature supported", "name": "warmest", "value": 500 } ], "property": "color_temp", "type": "numeric", "unit": "mired", "value_max": 500, "value_min": 153 }, { "access": 7, "description": "Color temperature after cold power on of this light", "name": "color_temp_startup", "presets": [ { "description": "Coolest temperature supported", "name": "coolest", "value": 153 }, { "description": "Cool temperature (250 mireds / 4000 Kelvin)", "name": "cool", "value": 250 }, { "description": "Neutral temperature (370 mireds / 2700 Kelvin)", "name": "neutral", "value": 370 }, { "description": "Warm temperature (454 mireds / 2200 Kelvin)", "name": "warm", "value": 454 }, { "description": "Warmest temperature supported", "name": "warmest", "value": 500 }, { "description": "Restore previous color_temp on cold power on", "name": "previous", "value": 65535 } ], "property": "color_temp_startup", "type": "numeric", "unit": "mired", "value_max": 500, "value_min": 153 }, { "description": "Color of this light in the CIE 1931 color space (x/y)", "features": [ { "access": 7, "name": "x", "property": "x", "type": "numeric" }, { "access": 7, "name": "y", "property": "y", "type": "numeric" } ], "name": "color_xy", "property": "color", "type": "composite" }, { "description": "Color of this light expressed as hue/saturation", "features": [ { "access": 7, "name": "hue", "property": "hue", "type": "numeric" }, { "access": 7, "name": "saturation", "property": "saturation", "type": "numeric" } ], "name": "color_hs", "property": "color", "type": "composite" } ], "type": "light" }, { "access": 2, "description": "Triggers an effect on the light (e.g. make light blink for a few seconds)", "name": "effect", "property": "effect", "type": "enum", "values": [ "blink", "breathe", "okay", "channel_change", "finish_effect", "stop_effect" ] }, { "access": 1, "description": "Link quality (signal strength)", "name": "linkquality", "property": "linkquality", "type": "numeric", "unit": "lqi", "value_max": 255, "value_min": 0 } ], "model": "9290012573A", "options": [ { "access": 2, "description": "Controls the transition time (in seconds) of on/off, brightness, color temperature (if applicable) and color (if applicable) changes. Defaults to `0` (no transition).", "name": "transition", "property": "transition", "type": "numeric", "value_min": 0 }, { "access": 2, "description": "When enabled colors will be synced, e.g. if the light supports both color x/y and color temperature a conversion from color x/y to color temperature will be done when setting the x/y color (default true).", "name": "color_sync", "property": "color_sync", "type": "binary", "value_off": false, "value_on": true } ], "supports_ota": true, "vendor": "Philips" }, "endpoints": { "11": { "bindings": [], "clusters": { "input": [ "genBasic", "genIdentify", "genGroups", "genScenes", "genOnOff", "genLevelCtrl", "touchlink", "manuSpecificPhilips2", "lightingColorCtrl", "manuSpecificUbisysDimmerSetup" ], "output": [ "genOta" ] }, "configured_reportings": [], "scenes": [] }, "242": { "bindings": [], "clusters": { "input": [ "greenPower" ], "output": [ "greenPower" ] }, "configured_reportings": [], "scenes": [] } }, "friendly_name": "0xaa55aa55aa55aa55", "ieee_address": "0xaa55aa55aa55aa55", "interview_completed": true, "interviewing": false, "manufacturer": "Signify Netherlands B.V.", "model_id": "LCT010", "network_address": 34172, "power_source": "Mains (single phase)", "software_build_id": "1.88.1", "supported": true, "type": "Router" }
zigbee2mqtt has individual device set up/review pages. You can see here that all the colors can be set up for example. The tooltip shows underlying stuff. In this case for color_hs.
-
Making great progress. The light is recognized and can be turned on & off. Also if I change the color with the zigbee2mqtt web page and then turn the light off and on in AltUI the color is retained.
Here is one observed issue: I have in my own code with a subscription to the occupancy sensor and using that to set a switch in VirtualHTTP. Has been working and has now stopped working. You see the code here - line 415.. Looks like something in openLuup has stopped that functioning? See error in log below:
luup_log:209: VirtualDevices[3.0-beta7@209](initializeMqtt@421):initializeMqtt(209,{ PowerStatusOff={ Value="0", Service="urn:upnp-org:serviceId:SwitchPower1", Variable="Status" }, BrightnessValue={ Variable="LoadLevelStatus", Service="urn:upnp-org:serviceId:Dimming1" }, PowerStatusOn={ Value="1", Service="urn:upnp-org:serviceId:SwitchPower1", Variable="Status" } }) - openLuup: true luup_log:209: VirtualDevices[3.0-beta7@209](subscribeToMqtt@414):subscribeToMqtt(209,nil,{ deviceID=209, opts={ Value="0", Service="urn:upnp-org:serviceId:SwitchPower1", Variable="Status" } }) openLuup.context_switch:: ERROR: [dev #209] ./L_VirtualLibrary.lua:415: attempt to concatenate field 'topic' (a nil value) openLuup.scheduler:: job aborted : ./L_VirtualLibrary.lua:415: attempt to concatenate field 'topic' (a nil value) openLuup.scheduler:: [211] Zigbee2MQTT device startup luup.set_failure:: status = 0 luup.variable_set:: 211.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0 luup.variable_set:: 211.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0 openLuup.scheduler:: [211] Zigbee2MQTT device startup completed: status=true, msg=OK, name=Zigbee2MQTTBridge
Start up of openLuup and then connecting to zigbee2mqtt server follows:
openLuup.mqtt:: CONNECT tcp{client}: 0x2d4a968 openLuup.mqtt:: ClientId: mqttjs_2080d9ee openLuup.mqtt:: WillTopic: zigbee2mqtt/bridge/state openLuup.mqtt:: WillMessage: {"state":"offline"} openLuup.mqtt:: UserName: **** openLuup.mqtt:: Password: **** openLuup.mqtt:: CONNECT tcp{client}: 0x25141a0 openLuup.mqtt:: ClientId: mqtt-explorer-27e89756 openLuup.mqtt:: WillTopic: openLuup.mqtt:: WillMessage: openLuup.mqtt:: UserName: **** openLuup.mqtt:: Password: **** openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x25141a0 openLuup.mqtt:: Packet Id: 0xa5b3 openLuup.mqtt:: Topic: # openLuup.mqtt:: mqtt-explorer-27e89756 SUBSCRIBE to # tcp{client}: 0x25141a0 openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x25141a0 openLuup.mqtt:: Packet Id: 0xa5b4 openLuup.mqtt:: Topic: $SYS/# openLuup.mqtt:: mqtt-explorer-27e89756 SUBSCRIBE to $SYS/# tcp{client}: 0x25141a0 openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x2d4a968 openLuup.mqtt:: Packet Id: 0x6437 openLuup.mqtt:: Topic: zigbee2mqtt/# openLuup.mqtt:: mqttjs_2080d9ee SUBSCRIBE to zigbee2mqtt/# tcp{client}: 0x2d4a968 openLuup.mqtt:: PUBLISH tcp{client}: 0x2d4a968 luup.zigbee2mqtt:0: Topic ignored : bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x2d4a968 luup.zigbee2mqtt:0: Topic ignored : bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x2d4a968 luup.zigbee2mqtt:0: Topic ignored : bridge/state openLuup.server:: request completed (871430 bytes, 55 chunks, 630 ms) tcp{client}: 0x29113e0 openLuup.server:: GET /data_request?id=user_data&output_format=json&DataVersion=768995292&_=1669768933474 HTTP/1.1 tcp{client}: 0x29113e0 openLuup.server:: request completed (1679360 bytes, 105 chunks, 1182 ms) tcp{client}: 0x29113e0
Restart of zigbee2mqtt server to force devices to be announced by the zigbee2mqtt server. You see the zigbee devices being detected and set up by openLuup.
openLuup.mqtt:: CONNECT tcp{client}: 0x2ac56b0 openLuup.mqtt:: ClientId: mqttjs_689eab85 openLuup.mqtt:: WillTopic: zigbee2mqtt/bridge/state openLuup.mqtt:: WillMessage: {"state":"offline"} openLuup.mqtt:: UserName: **** openLuup.mqtt:: Password: **** openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0 luup.zigbee2mqtt:0: Topic ignored : bridge/state openLuup.mqtt:: SUBSCRIBE tcp{client}: 0x2ac56b0 openLuup.mqtt:: Packet Id: 0x8099 openLuup.mqtt:: Topic: zigbee2mqtt/# openLuup.mqtt:: mqttjs_689eab85 SUBSCRIBE to zigbee2mqtt/# tcp{client}: 0x2ac56b0 openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0 luup.zigbee2mqtt:0: Topic ignored : bridge/info openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0 luup.zigbee2mqtt:0: New Zigbee detected: 0xRedacted1 luup.create_device:: [20001] D_GenericZigbeeDevice.xml / / D_GenericZigbeeDevice.json (GenericZigbeeDevice) luup.zigbee2mqtt:0: New Zigbee detected: 0xRedacted2 luup.create_device:: [20002] D_MotionSensor1.xml / / D_MotionSensor1.json (urn:schemas-micasaverde-com:device:MotionSensor:1) luup.zigbee2mqtt:0: New Zigbee detected: 0xRedacted3 luup.create_device:: [20003] D_DimmableLight1.xml / / D_DimmableLight1.json (urn:schemas-upnp-org:device:DimmableLight:1) openLuup.server:: request completed (16218 bytes, 2 chunks, 4645 ms) tcp{client}: 0x2456b18 openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0 luup.zigbee2mqtt:0: Topic ignored : bridge/groups openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0 luup.zigbee2mqtt:0: Topic ignored : bridge/extensions openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0 luup.zigbee2mqtt:0: Topic ignored : bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0 luup.zigbee2mqtt:0: Topic ignored : bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x2ac56b0
Here is the light being turned on & off noting that it actually does go on & off but I'm unclear about all the "Topic ignored". eg "0x_redacted_light_bulb/set/state"
openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=20003&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1 HTTP/1.1 tcp{client}: 0x28ba940 luup.call_action:: 20003.urn:upnp-org:serviceId:SwitchPower1.SetTarget luup.call_action:: action will be handled by parent: 211 luup.zigbee2mqtt:0: Topic ignored : 0x_redacted_light_bulb/set/state openLuup.server:: request completed (35 bytes, 1 chunks, 16 ms) tcp{client}: 0x28ba940 luup.watch_callback:: 12.urn:a-lurker-com:serviceId:Paradox_IP150_wps1.Zone_018 called [3]variableWatchCallback() function: 0x156a978 openLuup.mqtt:: PUBLISH tcp{client}: 0x2b88a08 luup.zigbee2mqtt:0: Topic ignored : bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x2b88a08 luup.zigbee2mqtt:0: Topic ignored : 0x_redacted_light_bulb luup.variable_set:: 10021.urn:micasaverde-com:serviceId:ZWaveNetwork1.LastPollSuccess was: 1669791951 now: 1669792831 #hooks:0 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=769116357&Timeout=60&MinimumDelay=1500&_=1669769862259 HTTP/1.1 tcp{client}: 0x1f620a0 openLuup.server:: request completed (7375 bytes, 1 chunks, 120 ms) tcp{client}: 0x1f620a0 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=769116361&Timeout=60&MinimumDelay=1500&_=1669769862260 HTTP/1.1 tcp{client}: 0x1f620a0 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=20003&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=1 HTTP/1.1 tcp{client}: 0x28ba940 luup.call_action:: 20003.urn:upnp-org:serviceId:SwitchPower1.SetTarget luup.call_action:: action will be handled by parent: 211 luup.zigbee2mqtt:0: Topic ignored : 0x_redacted_light_bulb/set/state openLuup.server:: request completed (35 bytes, 1 chunks, 4 ms) tcp{client}: 0x28ba940 openLuup.mqtt:: PUBLISH tcp{client}: 0x2b88a08 luup.zigbee2mqtt:0: Topic ignored : bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x2b88a08 luup.zigbee2mqtt:0: Topic ignored : 0x_redacted_light_bulb openLuup.server:: request completed (6642 bytes, 1 chunks, 3272 ms) tcp{client}: 0x1f620a0 openLuup.server:: GET /data_request?id=lu_status2&output_format=json&DataVersion=769116362&Timeout=60&MinimumDelay=1500&_=1669769862261 HTTP/1.1 tcp{client}: 0x1f620a0 openLuup.server:: GET /data_request?id=action&output_format=json&DeviceNum=20003&serviceId=urn:upnp-org:serviceId:SwitchPower1&action=SetTarget&newTargetValue=0 HTTP/1.1 tcp{client}: 0x28ba940 luup.call_action:: 20003.urn:upnp-org:serviceId:SwitchPower1.SetTarget luup.call_action:: action will be handled by parent: 211 luup.zigbee2mqtt:0: Topic ignored : 0x_redacted_light_bulb/set/state openLuup.server:: request completed (35 bytes, 1 chunks, 4 ms) tcp{client}: 0x28ba940 openLuup.mqtt:: PUBLISH tcp{client}: 0x2b88a08 luup.zigbee2mqtt:0: Topic ignored : bridge/logging openLuup.mqtt:: PUBLISH tcp{client}: 0x2b88a08 luup.zigbee2mqtt:0: Topic ignored : 0x_redacted_light_bulb openLuup.server:: request completed (6870 bytes, 1 chunks, 4973 ms) tcp{client}: 0x1f620a0
Here is the light being turned on & off being reported by zigbee2mqtt in the linux terminal.
Zigbee2MQTT:info 2022-11-30 18:20:30: MQTT publish: topic 'zigbee2mqtt/0x_redacted_light_bulb', payload '{"brightness":42,"color":{"x":0.5267,"y":0.4133},"color_mode":"color_temp","color_temp":500,"linkquality":224,"state":"ON"}' Zigbee2MQTT:info 2022-11-30 18:20:35: MQTT publish: topic 'zigbee2mqtt/0x_redacted_light_bulb', payload '{"brightness":42,"color":{"x":0.5267,"y":0.4133},"color_mode":"color_temp","color_temp":500,"linkquality":232,"state":"ON"}' Zigbee2MQTT:info 2022-11-30 18:20:40: MQTT publish: topic 'zigbee2mqtt/0x_redacted_light_bulb', payload '{"brightness":42,"color":{"x":0.5267,"y":0.4133},"color_mode":"color_temp","color_temp":500,"linkquality":224,"state":"OFF"}' Zigbee2MQTT:info 2022-11-30 18:26:51: MQTT publish: topic 'zigbee2mqtt/0x_redacted_occupancy_sensor', payload '{"battery":100,"detection_interval":30,"device_temperature":19,"illuminance":77,"linkquality":132,"motion_sensitivity":"medium","occupancy":false,"power_outage_count":0,"trigger_indicator":false,"voltage":3189}'
-
@a-lurker said in Migrating Zwave & ZigBee stuff to MQTT - guidance needed.:
Here is one observed issue: I have in my own code with a subscription to the occupancy sensor and using that to set a switch in VirtualHTTP. Has been working and has now stopped working. You see the code here - line 415.. Looks like something in openLuup has stopped that functioning? See error in log below:
This is clearly a nil topic value in the call. Where that is supposed to come from, I don't know.
@a-lurker said in Migrating Zwave & ZigBee stuff to MQTT - guidance needed.:
Here is the light being turned on & off noting that it actually does go on & off but I'm unclear about all the "Topic ignored". eg "0x_redacted_light_bulb/set/state"
The ignored topics are the reason that the openLuup device state is not changing – I simply haven't coded the monitoring side of things yet. The next step.
I'm unclear because of your log edits whether the devices are using their ieee_address or their friendly_name as MQTT topics. AFAIK, it's legal to use either? I need to make some extra arrangements if so.
Which devices are currently not being correctly identified?
-
"The ignored topics are the reason that the openLuup device state is not changing – I simply haven't coded the monitoring side of things yet" - makes sense. Yes next step.
"your log edits": - sorry about this. Being a bit paranoid. All the ieee_address(s) and their associated friendly_name(s) are equal to each other. I haven't changed them. They are still the hex "mac" addresses of the devices.
"AFAIK, it's legal to use either? " It would certainly appear so. The use of the friendly_name(s) would certainly be needed to do topic filtering. ie plus & hash. But I've made no attempt so far to change the friendly_name(s). Trying to keep the change in all the variables to a minimum.
"This is clearly a nil topic value in the call" - this is my separate code. I subscribe to the occupancy sensor and the openLuup handler routine is coded to set a virtual switch. Seems the topic is getting screwed up in the handler but may be red herring, so please don't take too much notice. However as far as I can see @thereadldb has not made any recent code changes.
"Which devices are currently not being correctly identified?" - errhh none! Working very well so far.If I need to provide more info please let me know.
-
@a-lurker said in Migrating Zwave & ZigBee stuff to MQTT - guidance needed.:
"Which devices are currently not being correctly identified?" - errhh none! Working very well so far.
Oh! ... wasn't expecting that!
Currently working on the device variable status updates.
-
@a-lurker said in Migrating Zwave & ZigBee stuff to MQTT - guidance needed.:
Being a bit paranoid.
I did, at least, replace username and password in the MQTT diagnostics with "****"!
These wouldn't anyway appear in the log at all if you had not enabled DEBUG in that module.
-
New testing version v22.11.30 should now mirror the device status (on/off and brightness) and also enable the openLuup device on/off control to work. Brightness level not yet implemented.
Battery levels should be shown too (once the device has woken up.)
Does the occupancy sensor work too?
-
@akbooer
Looking good - using AltUI for the following:Light bulb:
Works:
- on/off does control the bulb
- variable LoadLevelStatus reflects any brightness changes
- virtually all variables are loaded with a few exceptions - see below
Doesn't work:
- brightness slider (as you noted)
- light bulb icon does not change state in UI
- variable LoadLevelTarget is always zero
- variable linkquality is not loaded from the mqtt messages
- variable effect is not loaded from the mqtt messages
Motion detector:
Works:
- red dagger shows in UI when triggered
- last trigger time shows in the UI (30 secs later as per its set up parms)
- battery icon shows with percentage
- virtually all variables are loaded with a few exceptions - see below
Not loaded from the mqtt messages:
- detection_interval
- device_temperature
- illuminance
- illuminance_lux
- linkquality
- motion_sensitivity
- occupancy
- trigger_indicator
- voltage
Other:
- variable "BatteryLevel" (and UI icon) shows "100" and variable "battery" shows "numeric". mqtt exposes "battery", so maybe some mix up or duplication here. They're probably the same thing - one mios & one zigbee.
Start up problem:
Conditions:- devices have all been previously detected and built and are available in AltUI.
- the zigbee2mqtt server is running.
OK now restart openLupp. Status of all devices are not updated by any incoming mqtt messages from then on. Log says: "Topic Ignored : 0x_ieee_address".
Referring to file L_Zigbee2MQTTBridge.lua: function handle_friendly_names line 407 . Table "devices" is empty, so "dno" and "D" are nil.
Reason: it appears the "devices" table is loaded by "function init_device" and this is only called when the devices are first created in "function create_devices".
The devices table needs to be loaded if the devices have already been created. The work around is to restart the zigbee2mqtt server, so it publishes the topic "zigbee2mqtt/devices".
Logging:
Another slight issue with logging: The log showed for example on occasion : "bridge/logging" when it's actually "zigbee2mqtt/bridge/logging". The prefix zigbee2mqtt is missing and it makes a little unclear what topic is actually being ignored. Just makes it a bit harder to debug.Console -> openLuup -> About:
There is item labelled "Debug" - how do you set this to true?Everything is coming together!