seiq

Nope. I have a hard enough time getting Google to recognise "Fibaro" instead of Figaro or February haha

+1 for 2N intercoms. Amazing product for integrators. And +1 for support of H.264/RSTP/ONVIF or something better than god damn jpg!! Surely this has to be bumped into a higher priority. It's been requested for years and is standard in even the cheapest IP cams available.

Allow passing multiple camera id's to fibaro:call() function using the 'sendPhotoToEmail' and 'sendPhotoToUser' options to enable multiple images being sent in one email rather than the current capability of requiring multiple, single image emails. example: local camera_ids = { 101, 102, 103 } fibaro:call(camera_ids, "sendPhotoToUser", 2) Would also be great if a parameter object could optionally be passed with subject, body of message... local params = { subject = "Subject of email" body = "Message body of email" } fibaro:call(camera_ids, "sendPhotoToUser", 2, params)

Should be "propertyName" The line 115 error would be reported from within the LUA engine rather than the scene itself.

Np @Jamie mccrostie That scene will turn off all lights no matter which button you push as the for loop is outside your if statement. Also, find out how to use fibaro:getSourceTrigger() to save duplicating id's and property types Example with these modifications: --[[ %% properties 105 sceneActivation %% events %% globals --]] local sourceTrigger = fibaro:getSourceTrigger() -- fibaro:debug("sourceTrigger = " .. json.encode(sourceTrigger)) -- uncomment to debug contents of sourceTrigger table local scene = fibaro:getValue(sourceTrigger.deviceID, sourceTrigger.propertyName) if (scene == '26') then local ids = fibaro:getDevicesId( { interfaces = { "light", }, properties = { dead = false, }, enabled = true, visible = true, -- optional } ); -- loop through light ids for i, id in ipairs(ids) do fibaro:debug("Turning off " .. fibaro:getName(id)); -- turn light off fibaro:call(id, "turnOff"); end end

Here's another version that automatically adds users and scenes too. All room/device/scene/etc names are converted to lowercase (except the mobile device name so it can be copy/pasted from the Access Control settings page on HC2). ID's are available using the following format: HC2["zwave devices"]["room name"]["device name"] HC2["virtual devices"]["room name"]["device name"] HC2["mobile devices"]["device name"] HC2["scenes"]["room name"]["scene name"] HC2["users"]["user name"] --[[ %% autostart %% properties %% events %% globals --]] local global = "HC2" -- set to name of global variable to store table local debug = false -- Debug Output: true = enabled / false = disabled -- DO NOT EDIT BELOW THIS LINE function log(msg) if debug and msg then fibaro:debug(tostring(msg)) end end local http = { client = net.HTTPClient(), baseUrl = "http://127.0.0.1:11111/api/", } function http:new (parent) self.parent = parent return self end function http:failure (params) log("Failed loading " .. tostring(params.category) .. " (" .. tostring(params.error) .. ")") end function http:success (params) if params.response.status == 200 then log(params.category .. " information retreived") for n, data in pairs(json.decode(params.response.data)) do self.parent:add(params.category, data) end self.parent:save(params.category) else self:failure({category = params.category, error = params.response.status}) end end function http:get (category) if type(category) == "table" then for k, v in pairs(category) do self:get(v) end elseif category then -- validate category log("\r\nLOADING " .. category:upper() .. "...") self.parent.complete[category] = false self.client:request( self.baseUrl .. category, { success = function(status) self:success({category = category, response = status}) end, error = function(error) self:failure({category = category, error = error}) end } ) end end local this = { [global] = {}, -- global variable name to store table ["complete"] = {}, } function this:http () return http:new(self) end function this:save (category) fibaro:debug(category .. " information collated") self.complete[category] = nil for k, v in pairs(self.complete) do return nil end -- items still waiting completion fibaro:setGlobal("CreateGlobal", global) -- optional scene trigger to create new global fibaro:setGlobal(global, type(self[global]) == "table" and json.encode(self[global]) or self[global]) if not pcall( function() local test = json.decode(fibaro:getGlobalValue(global)) -- retrieve saved global if type(test) ~= "table" then error() end -- check global is a table log("\r\nGLOBAL " .. global .. " TABLE CONTENTS") log(json.encode(test)) fibaro:debug("Global ID's table '" .. global .. "' has been stored successfully") end ) then fibaro:debug("Failed to create global table :(") end end function this:add (category, data) if category == "users" or category:match("mobile") then self[global][category] = self[global][category] or {} -- intialise category table self[global][category][category:match("mobile") and data.name or data.name:lower()] = data.id elseif category == "scenes" or category:match("devices") then local room = (data.room or fibaro:getRoomName(data.roomID) and fibaro:getRoomName(data.roomID) or "unassigned"):lower() -- Fibaro bug workaround self[global][category] = self[global][category] or {} -- intialise category table self[global][category][room] = self[global][category][room] or {} -- initialise room table self[global][category][room][data.name:lower()] = data.id end end -- LOAD SCENES & USERS this:http():get({"scenes", "users"}) -- LOAD DEVICES local devices = { ["mobile devices"] = fibaro:getDevicesId( { enabled = true, type = "iOS_device" } ), ["virtual devices"] = fibaro:getDevicesId( { enabled = true, type = "virtual_device" } ), ["zwave devices"] = fibaro:getDevicesId( { visible = true, enabled = true, interfaces = { "zwave", }, } ), } log("\r\nLOADING DEVICES...") for category, list in pairs(devices) do log(category:upper() .. " ID's = " .. json.encode(list)) this.complete[category] = false for n, id in ipairs(list) do this:add( category, { id = id, name = fibaro:getName(id), room = fibaro:getRoomNameByDeviceID(id), } ) end this:save(category) end

Already requested -> [Feature Request] Resizable LUA Text Box

Pure Android Design Me either but Android app is surely a quick copy from iOS or they are using one of those cross platform development programs. It's been commented on many times.

@petergebruers Nah mate, no disagreement Your explanation was spot on! Figured topic was answered haha Just putting forward ideas for discussion on how this confusion could be solved and letting @speedy know he's not the only one suffering these dilemmas Great idea! Keep the global parameters in the master device so it doesn't seem like they are slave specific, correct?

Ha! I knew there was a possible 'evolution' comment on the way Yep, I get that. There were other signs of mismanaged development practice's in the past which is why I made the remark. Yes, the issue lies in changing the volkswagen beetle from a 'car' type in 2000 to a 'vehicle' type in 2016 without any backwards compatibility. It's all well and good changing identifying types for backend purposes but not cool when it affect's the end user experience. I'm sure most people would anticipate both dimmer versions to identify as the same type. They both provide the same basic, real world, functionality. IMHO the template/product types should be used in the backend and a generic 'device type' exposed for end user's. Even if it means Fibaro applying their own categorisation to each templated device. This way they could update the device type if, for example, a dimmer has parameters set to behave like a switch, it would report as a binarySwitch and an RGBW ID programmed to be a 4ch dimmer as a multiLevelSwitch, etc. Just thinking out aloud. I'm sure something can be done to simplify all this by someone much smarter than I... I know why the master/slave devices exist but am of the opinion the interface would be much clearer and cleaner if only the useful device ID's were ever displayed. The 'hidden' device view would become far more useable instead of the dumping ground it is now. Ideally from the GUI you'd only see: - 1 channel dimmer = 1 ID. - 2 channel relay = 2 ID's. - RGBW programmed for RGBW control = 1 ID (with 3 reserved) - RGBW programmed as 4 channel I/O = 4 ID's - Blind module = 1 ID - etc, etc

-1 Native android app first. [Que flamed responses ] Honestly don't know one person with a Windows phone in this neck of the woods.

100% agree with all of this. Fibaro haven't been known for great consistency in the past. Hopefully it's something they can look forward to rectifying in the future