dzVents 2.0 problem updating forecast in THB device

[manutremo]

Trying to start developing my own scripts with this great piece of software.

At this moment I'm facing the following issue with dzVents. Running domoticz 3.8024.

I'm using the following script to update a THB virtual device by merging pieces from other 2 other THB devices.

Code: Select all

return {
	active = true,
	on = {
		devices = {'Meteo terraza'},
	},

	execute = function(domoticz, device)
	    local t = device.temperature
	    local h = device.humidity
	    local hs = device.humidityStatus
	    local p = domoticz.devices('WU THB LEBL').barometer
	    local fcst = domoticz.devices('WU THB LEBL').forecast

	    domoticz.devices('Meteo terraza corregido').updateTempHumBaro(t, h, hs, p, fcst)
	end
}

However the forecast of the virtual device always comes up as "Unknown" (as of now the forecast in the originating device WU THB LEBL) is Sunny).

Any ideas on where the problem might be? Thanks!

[dannybloe]

I'll check tomorrow. Thanks for testing.

[dannybloe]

I just tried:

Code: Select all

domoticz.devices('thb').updateTempHumBaro(12, 88, domoticz.HUM_DRY, 1080, domoticz.BARO_SUNNY)

And that works:

Screen Shot 2017-07-02 at 11.56.13.png (69.01 KiB) Viewed 1682 times

You have to make sure to use the constants as described in the documentation otherwise Domoticz will not recognize your command.

[manutremo]

You have to make sure to use the constants as described in the documentation otherwise Domoticz will not recognize your command.

Many thanks for looking into it. The fact that it is a requirement to use the domoticz constants is very inconvenient - even in a simple example like this, I'd need to build a statement for each possible combination of humidity status and forecast, which would be too inconvenient. Given that they are just contants that are at some point just evaluated into a number, I think it would be a good idea that the number can be assigned directly or through the use of a variable.

Going ahead with my testing:

1.- I realized that the humidity status IS actualily being evaluated - although, incorrectly. See capture:



The device on the left is the "origin". As you see, it states "Comfortable" for the humidity status. This becomes copied into the device on the right by the script above (not using the domoticz constant, great!), but somehow it becomes "Normal".

I would also guess this points in the direction that it shouldn't be necessary that it is required that the forecast piece is updated using the domoticz constant.

2.- I modified my script for additional testing:

Code: Select all

return {
	active = true,
	on = {
	    timer = {'every minute'},
		--devices = {'Meteo terraza'},
	},

	execute = function(domoticz)
	    local t = domoticz.devices('Meteo terraza').temperature
	    local h = domoticz.devices('Meteo terraza').humidity
	    local hs = domoticz.devices('Meteo terraza').humidityStatus
	    local p = domoticz.devices('WU THB LEBL').barometer
	    local fcst = domoticz.devices('WU THB LEBL').forecast

	    domoticz.devices('Humedad').updateText(hs)
	    domoticz.devices('fcst').updateText(fcst)
	    
	    domoticz.devices('Meteo terraza corregido').updateTempHumBaro(t, h, hs, p, fcst)
	    domoticz.log('Meteo terraza corregido')
	end
}

I also created two text virtual decices in order to see the values stored for the humidity status and the forecast ("Humedad" and "fcst").

Now I'm getting the following error:

Code: Select all

 2017-07-02 20:16:00.322 dzVents: Info: ------ Start internal script: Meteo terraza:, trigger: every minute
2017-07-02 20:16:00.334 Error: dzVents: Error: There is no device with that name or id: WU THB LEBL
2017-07-02 20:16:00.334 Error: dzVents: Error: An error occured when calling event handler Meteo terraza
2017-07-02 20:16:00.334 Error: dzVents: Error: .../var/scripts/dzVents/generated_scripts/Meteo terraza.lua:12: attempt to index a nil value
2017-07-02 20:16:00.334 dzVents: Info: ------ Finished Meteo terraza 

However, the WU THB LEBL device exists, the spelling is correct and was actually working correctly before modifying the script.

Any ideas?

Many thanks for the effort of developing dzvents for those of us not super-experts in lua. I could still have a look into the code if you give me some hint of where to look if you think that could be of help.

Thanks!

[dannybloe]

what is exactly on line 12?

[dannybloe]

And I think you cannot use the forecast value from a device to set the forcast on another device. They are different values. Use the constants in the domoticz object as in my example.

[manutremo]

I'm just trying to help by reporting the findings during my testing in order to help with the development, providing suggestions and even offering my help. I thought that was expected and would be more appreciated in an open code effort.

I checked the code for the device adapter for the THB device and the way it's written it's true that it only supports passing the values using the constants. It wouldn't be too difficult to update the code to allow using both the domoticz constant and the raw value. On the other hand, the humidity status is not being "translated" at all (that's why at least a value different than "Unknown" is shown). Not difficult to fix either. I see other logic errors in the device adapter for the THB device.

You may probably be too busy ironing out the other higher priority bugs being reported, or maybe you are not accepting more contributors. No problem, I'll just fix my install myself and wait.

[EddyG]

I did not test it, but as far as I can see, when you request humidityStatus you will get a string.
When you post a humidityStatus to Domoticz it should be a constant in the range 0 - 3
Perhaps try to translate the 4 string to the corresponding numbers.
From the API and the JSON output of the device I see that only Forecast has a number and a string, humidityStatus has not.

Its a little bit strange. I have a MySensors BME280.
That gives me temp, hum and baro. I calculate the forecast and send those 4 values to Domoticz.
The hum_stat is then calculated by Domoticz from the value of humidity.
That is logic, because it should not be possible to have 99% hum and "Dry"

[dannybloe]

I'm just trying to help by reporting the findings during my testing in order to help with the development, providing suggestions and even offering my help. I thought that was expected and would be more appreciated in an open code effort.

I checked the code for the device adapter for the THB device and the way it's written it's true that it only supports passing the values using the constants. It wouldn't be too difficult to update the code to allow using both the domoticz constant and the raw value. On the other hand, the humidity status is not being "translated" at all (that's why at least a value different than "Unknown" is shown). Not difficult to fix either. I see other logic errors in the device adapter for the THB device.

You may probably be too busy ironing out the other higher priority bugs being reported, or maybe you are not accepting more contributors. No problem, I'll just fix my install myself and wait.

From what I remember when I wrote the adapter is that there is a discrepancy between TH and THB. They have different constants. So yeah, THB does some mapping to make it work so the user doesn't have to know there's a difference. I'm only creating a layer between de rough API world and the steady dzVents interface . At least I tried to.

But patches are happily accepted of course. After all, it's open source

[dannybloe]

I did not test it, but as far as I can see, when you request humidityStatus you will get a string.
When you post a humidityStatus to Domoticz it should be a constant in the range 0 - 3
Perhaps try to translate the 4 string to the corresponding numbers.
From the API and the JSON output of the device I see that only Forecast has a number and a string, humidityStatus has not.

Its a little bit strange. I have a MySensors BME280.
That gives me temp, hum and baro. I calculate the forecast and send those 4 values to Domoticz.
The hum_stat is then calculated by Domoticz from the value of humidity.
That is logic, because it should not be possible to have 99% hum and "Dry"

That would be more logical indeed. I don't know what happens if you don't provide that information. Maybe someone can investigate this a bit further and improve the adapters for TH and THB.