domoticz in synology as package! Available now.

[Gravityz]

things arge going fast.

i see you have build 794 on line but i need 795 to test the scene functionality.
also there seem sto be a bug in the qubino module.(device available in zwave but does not switch on/off because it complains the hardware can not be found)

this seems related to your build(the messages are about the qubino module)
does this have something to do with openzwave repo checkout.

2019-05-19 14:17:02.640 Error: OpenZWave: Exception. Type: 101, Msg: Invalid ValueID passed to GetValueLabel, File: /home/dahl/spksrc-master/spk/domoticz/work-apollolake-6.2/open-zwave-read-only/cpp/src/Manager.cpp (Line 1768)
2019-05-19 14:17:02.640 Error: OpenZWave: Exception. Type: 101, Msg: Invalid ValueID passed to GetValueLabel, File: /home/dahl/spksrc-master/spk/domoticz/work-apollolake-6.2/open-zwave-read-only/cpp/src/Manager.cpp (Line 1768)
2019-05-19 14:17:02.640 Error: OpenZWave: Exception. Type: 101, Msg: Invalid ValueID passed to GetValueLabel, File: /home/dahl/spksrc-master/spk/domoticz/work-apollolake-6.2/open-zwave-read-only/cpp/src/Manager.cpp (Line 1768)

[jumbotroll]

things arge going fast.

i see you have build 794 on line but i need 795 to test the scene functionality.
also there seem sto be a bug in the qubino module.(device available in zwave but does not switch on/off because it complains the hardware can not be found)

Ok, building 795 and will upload in 20 min...

[Gravityz]

thanks
tested it but scene functionality still not working.
for now i am going back to 734 because i do not want to run to long on a version which is not working properly (do not want this as a backup base)

is it possible to look at the errors which cause the qubino device not to work.
Accoording to Gizmocuz it might be related to the openzwave repo and the way things are compiled
also i do not understand why it complaining about a local file which is not local on my system but probably is on your system when you build the package

things arge going fast.

i see you have build 794 on line but i need 795 to test the scene functionality.
also there seem sto be a bug in the qubino module.(device available in zwave but does not switch on/off because it complains the hardware can not be found)

Ok, building 795 and will upload in 20 min...

[jumbotroll]

thanks
tested it but scene functionality still not working.
for now i am going back to 734 because i do not want to run to long on a version which is not working properly (do not want this as a backup base)

is it possible to look at the errors which cause the qubino device not to work.
Accoording to Gizmocuz it might be related to the openzwave repo and the way things are compiled
also i do not understand why it complaining about a local file which is not local on my system but probably is on your system when you build the package

Looking at it and trying to figure out what causes this..

[Gravityz]

here are 2 logfiles so you can see what happens when.
i know both module 8 and module 11 have experienced this error

OZW_Log.txt

(382.8 KiB) Downloaded 48 times

domoticz.log

(14.95 KiB) Downloaded 37 times

[Gravityz]

i figured something out.
They changed the openzwave config files when going to v1.6
some modules do not have problems with this but some do
My qubino ZMNHADx module has problems with the the 1.6 config files

in original 1.6 file at the end causing problems
module not working
OpenZWave: Exception. Type: 101, Msg: Invalid ValueID passed to GetValueLabel, File: /home/dahl/spksrc-master/spk/domoticz/work-apollolake-6.2/open-zwave-read-only/cpp/src/Manager.cpp (Line 1768)

Code: Select all

<CommandClass id="96">
    <Compatibility>
      <MapRootToEndpoint>true</MapRootToEndpoint>
    </Compatibility>
  </CommandClass>

when i change it back to the original v1.4 format is is working, no more errors and module works

Code: Select all

 <CommandClass id="96" mapping="endpoints" />
   </CommandClass>

i will mention this on github
it seems MapRootToEndpoint>true</MapRootToEndpoint is killing stuff (also on fibaro modules)

[Pacman42]

I still must remove and insert the USB cable after rebooting the NAS to get the RFXCOM to be detected.

Is there a solution to this described in this thread that I have missed, or must I put it behind a USB-hub that I automatically urn on via Domoticz after the NAS has restarted to get detection of the RFXCOM working automatically?

Edit: It is not even after every reboot that I manage to get the RFXCOM to connect, I might need to do several reboots...

[Pacman42]

Additional information. The issue is not occuring if I reboot the Synology with the RFXCOM disabled, but if it is enabled it happens most of the time. It seems like Domoticz is trying to grab the /dev/ttyUSB0 prior to it existing and that this is blocking it from being created.

I will try to grab logs etc, when I have some time over, perhaps during the weekend. But if someone already knows how to solve this, a description would be really appreciated. I am going away for several weeks in the summer and I really don't want to risk not getting access to receive and send over RFXCOM.

[Benj]

The Synology Domoticz package is adding the kernelmods for the /dev/ttyo at startup of the Domoticz package.
Normally such kernelmods are added to the kernel on booting of DSM.
So maybe they are not yet ready when Domoticz is starting.

You could test this by do a sleep after the kernel mods are inserted in the kernel and before Domoticz is started.
Change the file /var/packages/domoticz/scripts/start-stop-status
Add a sleep command just before Domoticz is started
So add the following on line 56 just befor the su ${USER} -c "${DOMOTICZ} ........
sleep 2

@jumbotroll
May I suggest the possibility that you add a script to the /usr/local/etc/rc.d folder in which you insert the kernel mods instead of doing it at the start of Domoticz?
All scripts with the extension .sh in that folder are run by DSM at boot time with "start" as parameter and run again at shutdown of DSM with the "stop" as parameter.
The permission of that script file must be 755.

[Gravityz]

I do not have these problems at all

I have a Ds718+. And frxcom xl

Dsm 6.2

[Benj]

If it is a timing problem it is most likely device dependent and also dependent how busy the Nas is starting other packages.
So it is word a try to add the sleep.

Another way to test is would be to stop the Domoticz package, reboot the system, wait until everything is running and the cpu usage is settled down and only then start the Domoticz package.

By the way:
I tested it on my test Nas a DS116 with Domoticz and a RFXCOM 433 and could not reproduced this problem, but this Nas is not running any other package so a timing problem is less likely to happen here.

[Pacman42]

Thanks, your proposal fits my analysis perfectly, even though I had not yet looked into the installation of the modules. I have several packages running on an DS216j (which is rather weak).

My next planned step was actually to insert a sleep for three minutes into the start-script of Domoticz, so I was perhaps on the right track...

Tanks again, I'll come back with results tonight (I hope).

[Pacman42]

Thinking a minute more about it, the problem is likely that the USB device is detected prior to the modules are inserted. But then another issue floats up to the surface, why isn't it possible to unplug-plug the USB connector after boot to get it working? /dev/ttyUSB0 is not available even after an unplug-plug sequence after booting if the device is not found during boot and Domoticz has tried to access it. So there must be two issues in the Domoticz start-up script:
1) the modules are inserted too late in the start sequence (on my NAS)
2) unplug-plug of the USB is not triggering another try

I must look further into the details of this tonight...

[Benj]

I have a theorie about this.
When the domoticz start script runs it first load the kernel mods and then it starts domoticz.
When the kernel mods are not ready when Domoticz start it does not find the kernel mods and will not see the /dev/ttyUSB0 device and will not try to find them ever again.
As I said just a theorie, because I don't know how Domoticz does it, but that is what I suspect is happening.
Because normally a kernel mod should be loaded at boottime of the Operating System and not by means of a start script of an application.
So an application would normally do an inventory which device are present only at startup of the application.

As I said, it can be tested by shutting down Domoticz in the package centre, reboot the Nas, wait a while until all package are running.
The start Domoticz in the package centre.

[Gravityz]

please check this is not a persistent usb problem.

https://www.domoticz.com/wiki/Assign_fi ... o_USB_port

[Benj]

On a Synology that can only happen if you physically switch the usb connectors.

[Pacman42]

OK, adding a 3min delay on the row prior to starting Domoticz did the trick. So it is a timing issue.

The next solution is of course to run a loop with "sudo ls /dev/tty*|grep -c ttyUSB0" every five seconds during two minutes or until the device is created. That is a nicer workaround (if one actually has an RFXCOM).

The best thing would be a flag that tells whether an RFXCOM is configured and then the loop is run prior to Domoticz is started to ensure that Domoticz waits for the configured RFXCOM. I really don't know where to psuh that in (the flag is easy, but how update Domoticz to put it in if RFXCOM is configured?)

[Gravityz]

if have had this issue on a DS112+ so this can happen without unplugging ports

On a Synology that can only happen if you physically switch the usb connectors.

[Benj]

A better way would be the use of lsusb, then you can actually test on the availability of the RFXCOM
lusb -i will show all needed information

In the script you could use this line:
lsusb | grep RFXCOM


@gravityz

ttyusb number are assigned starting from the lowest USB port to the highest starting with the first available ttyUSB number which will be ttyUSB0 if the OS had not yet installed his own ttyUSB device.

So if you have and rfxcom on the first USB port and a smartmeter on the second port then ttyUSB0 will always be assigned to the RFXCOM and ttyUSB1 to the smartmeter.
Only when an insmod on the first will fail it is possible that the schema shift a number and you will and up with for example ttyUSB1 and ttyUSB2 but in that case you should find why it has failed.
The other possibility is that a failure of the insmod for the RFXCOM module and then you would end up with no RFXCOM and the smartmeter on ttyUSB0

[Pacman42]

The driver is called FT232 on my RFXCOM, so this is the result:

Code: Select all

 
    for ii in (1..24)
    do
      ftdi=`lsusb|grep -c "FT232"`
      if [ $ftdi -gt 0 ]
      then
        break
      else
        sleep 5
      fi
    done
    su ${USER} -c "${DOMOTICZ} -www ${PORT} -wwwroot ${WWWROOT} -sslwww ${RSSLPORT} ........................
  

I will perhaps look further into this later, but I am happy with this for now. Someone may of course work on a better more generic solution if they want to. I am however not prioritizing that for the moment. But one should of ourse not have start scripts that run into this situation, even if it is rare.