Domoticz

hasan wrote:

toffel969 wrote:Hello everyone
Im expieriencing exactly the same problem, module bassex not found.

Code: Select all

luarocks list

returns

Code: Select all

Installed rocks:
----------------

basexx
   0.3.0-1 (installed) - /usr/local/lib/luarocks/rocks

luasec
   0.6-1 (installed) - /usr/local/lib/luarocks/rocks

luasocket
   3.0rc1-2 (installed) - /usr/local/lib/luarocks/rocks

Code: Select all

lua 

gives me

Code: Select all

Lua 5.2.3  Copyright (C) 1994-2013 Lua.org, PUC-Rio
>

Maybe just an addition, I had to install

Code: Select all

sudo apt-get install libssl-dev

in order to install luasec, as this is the only thing that resolved the "openssl" not found issue during the build process.

I followed the wiki step by step last night, but am stuck at this point right now. Does anyone see where I'm going wrong ?

Hi, I did some adjustment of Wiki, so you should try it. You will need these two files:
usrlocalsharelua5p2.tar
usrlocalliblua5p2.tar

Hi Hasan

Sorry for having to ask again, the instructions where to put them and the files got somehow removed from the wiki, I couldn't find it in the history (strange as I saw them yesterday from work). Could you please be so kind as to post them again.

Update: Never mind I was to silly to see it at the bottom of the page...

Hold your horses! It just occurred to me that it will report 0 degrees whenever the valve doesn't communicate its temperature. That is probably not what you want. So I changed the code again. Plus I uncommented it already, since your explanation convinced me that more people might be interested. You can always choose not to add the sensor to the list of used devices.

You was right. During the night I have got couple times temperature of 25.5 decrees from room without WMT. I checked with maxtest.lua that received current radiator temperature is really 0 decrees. So thermostat valve looses it's current temperature. There hasn't been any change in setpoint during that time so could it be reason for strange temperature readings?

I changed setpoint and after that reported temperature returned from 25.5 decrees to value it should be.

Teatech wrote:I changed setpoint and after that reported temperature returned from 25.5 decrees to value it should be.

Valves don't communicate their temperature when they have not been active for a while, and since a variable always needs to have a value, the script gives it a value of zero in such cases.

In another part of the script, values below 5 degrees (so also 0 degrees) are converted to their value + 25.5, which explains your readings. This is done because there is an "interesting" phenomenon in the communication with the MAX! devices, where temperatures above 25.5 degrees are reported as their value minus 25.5. Has to do with only two hex digits being used for temp.

Anyway, I have made a small change to prevent this from happening again. You basically only have to change "if temp ~= 0 then" into "if temp ~= 25.5 then"

Ok.
Now I have updated both script and Domoticz. Everything seems running well. Thanks again!

Teatech wrote:Ok.
Now I have updated both script and Domoticz. Everything seems running well. Thanks again!

Great! Let me know if you run into something, like frequent (timeout) error messages or devices that stop updating.

Thanks for all the testing work you did! With your help I think we already got to a quite mature level in a short time.

Now and then there has been warning about script runing over 10 secs but not too many. I remember you mentioned about it.
You also run Domoticz in Raspberry, yes? What version? I have on my desk almost unused Raspberry 3. I noticed that it's quite lot faster than previous version 2B that I have for Domoticz now. Maybe I'll change Domoticz to that if I start to receive too many warnings. Maybe it helps?
I bought that new version for Domoticz but I haven't had time to make change. And I also had problems to get touch screen monitor to work with it. But that another thing and don't belong to this topic.

It's possible that the 10 second errors are caused by using LUA to update a setpoint.

Westcott wrote:It's possible that the 10 second errors are caused by using LUA to update a setpoint.

The script only uses JSON API calls to change sensors and setpoints.

I noticed in the log that there is approximately 1 second between the time stamps at which the sensors/setpoints are actually updated. Polling the Cube also takes a second or so. It could very well be that all http communication sometimes takes more than 10 seconds in total, especially when more than a few valves & thermostats are polled and uodated.

If this becomes a real problem, we may need to look for other solutions. But at the moment I only have one of such messages per few hours, and even though an error message is given it still seems to update all sensors perfectly.

Teatech wrote:Now and then there has been warning about script runing over 10 secs but not too many. I remember you mentioned about it.
You also run Domoticz in Raspberry, yes? What version? I have on my desk almost unused Raspberry 3. I noticed that it's quite lot faster than previous version 2B that I have for Domoticz now. Maybe I'll change Domoticz to that if I start to receive too many warnings. Maybe it helps?
I bought that new version for Domoticz but I haven't had time to make change. And I also had problems to get touch screen monitor to work with it. But that another thing and don't belong to this topic.

Interesting! I'm curious if this helps, if it does I will also consider buying a Raspberry Pi 3.

By the way, I'm pretty sure you can easily try it out by simply switching micro SD cards. Even though the Pi 3 has a slightly different architecture, and special images are available for it, I understood that it should be compatible with images for the Pi 2B.

MvZut,

Just tried your version.

On run one ive got:
And it created the MAX Virual Hardware Device

On the 2nd Run ive got:
And it created the devices Thermostat Setpoint and Valve percentages.. Unfortunetly nameless(So i have to figure aut what is what)

On the 3rd run it updated the devices
*EDIT*

I then switched back to the WIKI Version of the script.. And this produces no errors.

Skippiemanz wrote:MvZut,

Just tried your version.
...
And it created the devices Thermostat Setpoint and Valve percentages.. Unfortunetly nameless(So i have to figure aut what is what)
On the 3rd run it updated the devices
...
I then switched back to the WIKI Version of the script.. And this produces no errors.

Thanks for testing it Skippiemanz! Good to know it works on more installations.

By the way, there's a little trick you could use which will make it easier to find out which newly created Domoticz device belongs to which MAX! module: if you run the maxtest.lua script from the Wiki, it will show an address for each module. In the devices page of Domoticz, al new "Unknown" devices use this address as their ID. This should make it easy to find which MAX! module it belongs to.

Your error messages regarding the JSON.lua scipt are new to me, I have never seen those. I must admit I am using another version of json.lua from http://regex.info/blog/lua/json. If somebody else encounters such error messages, they could try that version.

Hi all,
I tried the new code but I get this I named my script script_time_maxauto.lua so that I could swap easily with filezilla
Sean

blackdog65 wrote:Hi all,
I tried the new code but I get this

Code: Select all

2016-11-12 11:25:00.310 Error: EventSystem: in /home/linaro/domoticz/scripts/lua/script_time_maxauto.lua: /home/linaro/domoticz/scripts/lua/JSON.lua:660: html passed to JSON:decode():
401 Unauthorized

I named my script script_time_maxauto.lua so that I could swap easily with filezilla
Sean

This probably means that you have set a password to Domoticz, which prevents JSON commands from being sent to Domoticz (even though Domoticz is actually sending them to itself ). This can be solved by adding 127.0.0.* to the list of local networks under Settings. Let me know if this helps.

Ah! I had 192.168.1.* but obviously not enough
Is the MAX! hardware device created automatically or do I need to create it?

Sean

blackdog65 wrote:Is the MAX! hardware device created automatically or do I need to create it?

Sean

Double oops it just popped up, I'll wait for the next pass to see if it populates

Sean

mvzut wrote:Your error messages regarding the JSON.lua scipt are new to me, I have never seen those. I must admit I am using another version of json.lua from http://regex.info/blog/lua/json. If somebody else encounters such error messages, they could try that version.

Just installed my own door/window sensor, and it created a temperature sensor (?) for it... It sunddenly also started giving me the json.lua error messages that you had. So the version of the json script has nothing to do with this error message.

I made a small change to the script (see few pages back) to prevent this, but it is a very quick-and-dirty solution: I have set my thermostats to manual mode, but the door sensor is always in auto mode. This is how I detect it, and how I prevent it from being processed by the script.

I will look into the datagrams coming from the Cube more carefully, and see if I can properly detect a door sensor and its status.

blackdog65 wrote:

blackdog65 wrote:Is the MAX! hardware device created automatically or do I need to create it?

Sean

Double oops it just popped up, I'll wait for the next pass to see if it populates

Sean

Do you have door/window sensors? If so, please use the latest script to prevent errors.

mvzut wrote: By the way, there's a little trick you could use which will make it easier to find out which newly created Domoticz device belongs to which MAX! module: if you run the maxtest.lua script from the Wiki, it will show an address for each module. In the devices page of Domoticz, al new "Unknown" devices use this address as their ID. This should make it easy to find which MAX! module it belongs to.

That is just the way I used to identify devices, very easy. Of cource it would be easyer to start using script if everyting happens automatically. But it's quite easy already.

I have also received those 10 sec run warnings. But as I mentioned earlier that happens only few times a day so it doesn't really matter.
And because I only have 3 devices that communicates with cube/domoticz I can't be sure what part uses too much time while script is running. I have noticed that in my case using MAX! software directly all happens quite fast. Problem might be in communication between cube and devices in case that signal strength is poor or disturb. That may also explain why it happend only irregulary; there is some other RF communication at that channel at time of MAX! tryes to communicate with own devices. Because RF communication takes longer causes delay in http communication also.

It is very common that devices that uses RF communication like temperature/humidity meters that may communicate only one way (saves power) tryes to send data irregulary to avoid conflicts with other RF devices. It helps to get message trough even sometimes.
It would be nice to have sniffer to check radio communication. I also use 433MHz RFLink and I got lots of devices that I really don't know what they are. But I'm sure they are not mine.

Teatech wrote:Problem might be in communication between cube and devices in case that signal strength is poor or disturb. That may also explain why it happend only irregulary; there is some other RF communication at that channel at time of MAX! tryes to communicate with own devices. Because RF communication takes longer causes delay in http communication also.

I think that when you request the current status from the Cube using http communication, the Cube doesn't actually poll the devices at that moment. The Cube, thermostats and valves communicate with each other anyway, regardless of whether you poll them or not. The Cubes stores the last known values for displaying when you open the web inteface, or when information is requested by an app or via http commands. If you run the test script, it always displays the results in a second or so. So I'm pretty sure this cannot be where the timeout errors come from.

About the identification: I will investigate if there is a method to automatically add & name the newly created devices using JSON commands, but so far I havent found it. I can add devices with a name, but only a few types seem to be available for this, not thermostats. Moreover, the method that I use now also has its advantages, since you can now give the new devices any name you like, and renaming them later will not mess up the max update script.