dzVents 2.4.0 merged into Beta v3.8837+

[EddyG]

This is just the output of the Lux device:

Code: Select all

{
   "ActTime" : 1516901014,
   "AstrTwilightEnd" : "19:11",
   "AstrTwilightStart" : "06:29",
   "CivTwilightEnd" : "17:50",
   "CivTwilightStart" : "07:50",
   "DayLength" : "08:45",
   "NautTwilightEnd" : "18:31",
   "NautTwilightStart" : "07:09",
   "ServerTime" : "2018-01-25 18:23:34",
   "SunAtSouth" : "12:05",
   "Sunrise" : "08:27",
   "Sunset" : "17:13",
   "result" : [
      {
         "AddjMulti" : 1.0,
         "AddjMulti2" : 1.0,
         "AddjValue" : 0.0,
         "AddjValue2" : 0.0,
         "BatteryLevel" : 255,
         "CustomImage" : 0,
         "Data" : "1 Lux",
         "Description" : "",
         "Favorite" : 0,
         "HardwareID" : 24,
         "HardwareName" : "RaZberry",
         "HardwareType" : "OpenZWave USB",
         "HardwareTypeVal" : 21,
         "HaveTimeout" : false,
         "ID" : "0001003",
         "LastUpdate" : "2018-01-25 16:47:59",
         "Name" : "PIR Achterkamer Lux",
         "Notifications" : "false",
         "PlanID" : "0",
         "PlanIDs" : [ 0 ],
         "Protected" : false,
         "ShowNotifications" : true,
         "SignalLevel" : "-",
         "SubType" : "Lux",
         "Timers" : "false",
         "Type" : "Lux",
         "TypeImg" : "lux",
         "Unit" : 255,
         "Used" : 1,
         "XOffset" : "0",
         "YOffset" : "0",
         "idx" : "417"
      }
   ],
   "status" : "OK",
   "title" : "Devices"
}

This part of the script:

Code: Select all

return {

        active = true,
--      active = false,

        on = {
                devices = { 'PIR*' }
        },

        execute = function(domoticz, detector)

print( '<b style="color:Red">>> ' .. detector.switchType )
                if detector.switchType == 'Motion Sensor' then
                        print('<b style="color:DarkOrange">>> ' .. detector.name  .. ' - ' .. detector.state )
                        .......
                end
        end
}

[dannybloe]

So there aren’t any other devices whose name start with PIR? As you are using a wildcard.

[EddyG]

I have 4 PIR* hardware devices, 3 from NeoCool and 1 from Fibaro.
Ofcourse each give several devices.
I use only the Motion, Temp and Lux devices.
Here is a Lux device that has a switchType "On/Off" and that's not normal.
I want to use the switchType to do different things when a device triggers.
Motion triggers more than Temp and Lux.

[dannybloe]

Can you start a new topic in bugs and describe your problem again with a full dump of domoticzData.lua (debug
Mode). We will continue there. This is off-topic for this thread.

[elmortero]

Hi dannybloe,

Is there any chance that checkFirst will be extended to Text sensors too?
That way you can avoid updating a text sensor with the same value over and over (unless the script checks that first of course)

[Eoreh]

Is future or bug ? In "Logs" we lost in dzVents "RED" color for "LOG_ERROR" ?
for eg line like this -> domoticz.log('TEST', domoticz.LOG_ERROR)

eg3.png (1.44 KiB) Viewed 3566 times

I think we need We need a larger selection of colors, no less

[jake]

I just updated to Beta 3.8872 and came across some error

Code: Select all

onkyomode.switchSelector(domoticz.data.KodiAudioMode).afterSec(onkyo_delay).silent().checkFirst()

gives the log error

Code: Select all

dzVents: Error (2.4.1): /home/pi/domoticz/scripts/dzVents/scripts/kodi.lua:68: attempt to call field 'checkFirst' (a nil value)

I assume a switchselector has always a value, therefore not being able to be 'nil'.

Secondly, has the option for using the more standard LUA way: otherdevices_svalues been removed?

Code: Select all

DHW_GasLua = otherdevices_svalues['DHW gas']

results in log error

Code: Select all

dzVents: Error (2.4.1): /home/pi/domoticz/scripts/dzVents/scripts/GasMeterCheck.lua:23: attempt to index global 'otherdevices_svalues' (a nil value)

[manutremo]

Hi,

I just upgraded to 3.8841 and started to get this error in the log everytime a dzVents script tries to execute:

Error: EventSystem: in /usr/local/domoticz/var/dzVents/runtime/dzVents.lua: /usr/local/domoticz/var/dzVents/runtime/dzVents.lua:33: attempt to concatenate local 'triggerReason' (a nil value)

Not sure if it will be related but after activating dzVents debug, I'm getting:

dzVents: Debug: Dumping domoticz data to /usr/local/domoticz/var/scripts/dzVents//domoticzData.lua
dzVents: Debug: dzVents version: 2.3.0

Shouldn't I be seeing dzVents version 2.4.0 with this version of Domoticz?

[dannybloe]

You have a mixup of old and new. This is not a standard distribution that you have.

[Eoreh]

Code: Select all

print( '<b style="color:Red">>> ' .. detector.switchType )
                if detector.switchType == 'Motion Sensor' then
                        print('<b style="color:DarkOrange">>> ' .. detector.name  .. ' - ' .. detector.state )
                       .......

Thx for nice tip regarding the possibility of coloring in the log !

[jake]

I just updated to Beta 3.8872 and came across some error

Code: Select all

onkyomode.switchSelector(domoticz.data.KodiAudioMode).afterSec(onkyo_delay).silent().checkFirst()

gives the log error

Code: Select all

dzVents: Error (2.4.1): /home/pi/domoticz/scripts/dzVents/scripts/kodi.lua:68: attempt to call field 'checkFirst' (a nil value)

I assume a switchselector has always a value, therefore not being able to be 'nil'.

Secondly, has the option for using the more standard LUA way: otherdevices_svalues been removed?

Code: Select all

DHW_GasLua = otherdevices_svalues['DHW gas']

results in log error

Code: Select all

dzVents: Error (2.4.1): /home/pi/domoticz/scripts/dzVents/scripts/GasMeterCheck.lua:23: attempt to index global 'otherdevices_svalues' (a nil value)

Besides the mentioned items here above, I came across 2 things while working on a script to influence the OTGW setpoint:

.updateSetPoint(xyz).checkFirst() is not accepted, like as with the switchSelector

while giving the .updateSetpoint() command, the log returns the following error:

Code: Select all

2018-02-04 23:39:00.666 EventSystem: Script event triggered: /home/pi/domoticz/dzVents/runtime/dzVents.lua
2018-02-04 23:39:00.701 Error: Error opening url: http://127.0.0.1:8080/json.htm?type=command¶m=udevice&idx=87&nvalue=0&svalue=17.5

Of course, when I replace the '¶m' with '&param' in a browser window, the json call works as expected.

I tried fixing the dzVents device adapter.lua by replacing the ampersand '&' symbol by ' .. string.char(38) .. '
Unfortunately this is handled identical to the original string and gives the same error in the log file.

[jake]

In this topic the suggestion is done to change the 'param=udevice' and 'type=command' around. I did this and now the log tells me

Code: Select all

2018-02-05 23:13:00.553 Error: Error opening url: http://127.0.0.1:8080/json.htm?param=udevice&type=command&idx=87&nvalue=0&svalue=17.5

quite weird, since I can copy the exact http command (only changing the 127.0.0.1 to the internal IP-address of the RPI: 192.168.etc) in the browser window and have it running alright with an acknowledgement that it has run correctly.

So, I went back to the opentherm_gateway_device.lua and modified the lines

Code: Select all

local url = domoticz.settings['Domoticz url'] .. 
               '/json.htm?type=command&param=udevice&idx=' .. device.id .. '&nvalue=0&svalue=' .. setPoint

to

Code: Select all

local url = 'http://192.168.myIP:8080' .. 
               '/json.htm?param=udevice&type=command&idx=' .. device.id .. '&nvalue=0&svalue=' .. setPoint 

and now it works out of the box.
So 2 changes:
- moving param and type around
- moving the local host IP address 127.0.0.1 (coming from domoticz settings) to the internal IP address that the RPI has on the network

[waaren]

Hi Danny,

while investigation the possibility to (re)set one of the zones of my evohome installation to auto, I noticed that dzVents did not recognize my Evohome via Web API device as evohome resulting in the message:

Code: Select all

dzVents: Error (2.4.1): Method updateSetPoint is not available for device "Slaapkamer" (deviceType=Heating, deviceSubType=Zone). If you believe this is not correct, please report.

using the dump() method I notitced that my device was hardwareType 75 and device-adapters/evohome_device.lua checks on hardwareTypeValue == 39
at line 10:

Code: Select all

local res = ( device.hardwareTypeValue == 39 ) and device.deviceSubType == 'Zone')

after changing line 10 to

Code: Select all

local res = (( device.hardwareTypeValue == 39 or device.hardwareTypeValue == 75 ) and device.deviceSubType == 'Zone')

the line of code:

Code: Select all

domoticz.devices('Slaapkamer').updateSetPoint(nil, Auto,nil )

now works as expected.

Question: should we use a separate device-adapter for this or is it ok to leave it like this ?

[dannybloe]

Hi Danny,

while investigation the possibility to (re)set one of the zones of my evohome installation to auto, I noticed that dzVents did not recognize my Evohome via Web API device as evohome resulting in the message:

Code: Select all

dzVents: Error (2.4.1): Method updateSetPoint is not available for device "Slaapkamer" (deviceType=Heating, deviceSubType=Zone). If you believe this is not correct, please report.

using the dump() method I notitced that my device was hardwareType 75 and device-adapters/evohome_device.lua checks on hardwareTypeValue == 39
at line 10:

Code: Select all

local res = ( device.hardwareTypeValue == 39 ) and device.deviceSubType == 'Zone')

after changing line 10 to

Code: Select all

local res = (( device.hardwareTypeValue == 39 or device.hardwareTypeValue == 75 ) and device.deviceSubType == 'Zone')

the line of code:

Code: Select all

domoticz.devices('Slaapkamer').updateSetPoint(nil, Auto,nil )

now works as expected.

Question: should we use a separate device-adapter for this or is it ok to leave it like this ?

Ah, thanks for reporting. I have EvoHome as well but never got to actually using it like you do. I will add this to my todo and figure out if it should be a separate adapter.

[dannybloe]

I just updated to Beta 3.8872 and came across some error

Code: Select all

onkyomode.switchSelector(domoticz.data.KodiAudioMode).afterSec(onkyo_delay).silent().checkFirst()

gives the log error

Code: Select all

dzVents: Error (2.4.1): /home/pi/domoticz/scripts/dzVents/scripts/kodi.lua:68: attempt to call field 'checkFirst' (a nil value)

I assume a switchselector has always a value, therefore not being able to be 'nil'.

That's correct. A selector switch doesn't have a 'clean' state value to check internally (it's Set Level 20 or something like that). So I will have to extend the checkFirst() functionality to support this as well.

Secondly, has the option for using the more standard LUA way: otherdevices_svalues been removed?

Code: Select all

DHW_GasLua = otherdevices_svalues['DHW gas']

results in log error

Code: Select all

dzVents: Error (2.4.1): /home/pi/domoticz/scripts/dzVents/scripts/GasMeterCheck.lua:23: attempt to index global 'otherdevices_svalues' (a nil value)

Yep, that's gone. There's absolutely no need to use those ancient tables anymore in dzVents. You can always use rawData which is exactly what you found in sValues earlier. But even then... rawData should not be necessary at all so if you miss specific device attributes let me know and we will adjust or create the proper device adapters to fix this.

[dannybloe]

In this topic the suggestion is done to change the 'param=udevice' and 'type=command' around. I did this and now the log tells me

Code: Select all

2018-02-05 23:13:00.553 Error: Error opening url: http://127.0.0.1:8080/json.htm?param=udevice&type=command&idx=87&nvalue=0&svalue=17.5

quite weird, since I can copy the exact http command (only changing the 127.0.0.1 to the internal IP-address of the RPI: 192.168.etc) in the browser window and have it running alright with an acknowledgement that it has run correctly.

So, I went back to the opentherm_gateway_device.lua and modified the lines

Code: Select all

local url = domoticz.settings['Domoticz url'] .. 
               '/json.htm?type=command&param=udevice&idx=' .. device.id .. '&nvalue=0&svalue=' .. setPoint

to

Code: Select all

local url = 'http://192.168.myIP:8080' .. 
               '/json.htm?param=udevice&type=command&idx=' .. device.id .. '&nvalue=0&svalue=' .. setPoint 

and now it works out of the box.
So 2 changes:
- moving param and type around
- moving the local host IP address 127.0.0.1 (coming from domoticz settings) to the internal IP address that the RPI has on the network

You have to allow 127.0.0.1 to access the API in the Domoticz settings (see getting started in the documentation). Then this should work.

[jake]

...
So 2 changes:
- moving param and type around
- moving the local host IP address 127.0.0.1 (coming from domoticz settings) to the internal IP address that the RPI has on the network

You have to allow 127.0.0.1 to access the API in the Domoticz settings (see getting started in the documentation). Then this should work.

Thanks, I had to go through the Wiki 3 times before I found the section about 127.0.0.1, but ... it did the trick. The solution wasn't that obvious, based on the error in the log. In order to help other users: is it possible to add this solution suggestion to the error when it occurs?

The change around of param and type is still necessary. Although I see the issue of malformed json commands in more topic on the forum (therefore not specifically dzVents?), this is still a problem to use this specific device adapter in dzVents. Will you permanently change the 2 parameters around? I guess that at an update of Domoticz my adapation is overwritten by the default file.

[dannybloe]

...
So 2 changes:
- moving param and type around
- moving the local host IP address 127.0.0.1 (coming from domoticz settings) to the internal IP address that the RPI has on the network

You have to allow 127.0.0.1 to access the API in the Domoticz settings (see getting started in the documentation). Then this should work.

Thanks, I had to go through the Wiki 3 times before I found the section about 127.0.0.1, but ... it did the trick. The solution wasn't that obvious, based on the error in the log. In order to help other users: is it possible to add this solution suggestion to the error when it occurs?

This is very hard to do because this is beyond dzVents. The url is opened by Domoticz and the error occurs way after dzVents has finished so I cannot catch the error. Weird that you couldn't find it in the docs.. it's in the second chapter just after the introduction.

The change around of param and type is still necessary. Although I see the issue of malformed json commands in more topic on the forum (therefore not specifically dzVents?), this is still a problem to use this specific device adapter in dzVents. Will you permanently change the 2 parameters around? I guess that at an update of Domoticz my adapation is overwritten by the default file.

I'll look into it.

[Charley]

I am trying to allow access to the API through 127.0.0.1 but I am not able to find the solution for Raspberry PI
Is there anyone who can help me out.

[SweetPants]

I am trying to allow access to the API through 127.0.0.1 but I am not able to find the solution for Raspberry PI
Is there anyone who can help me out.

What do you mean with API? If it is JSON commands, allow access to 127.0.0.1 in setup->settings->Local Networks if you want to use it without authentication