EventGhost

Well, I remember I had problems with the MQTT setup when I first started to use ONH and EG, which I think is why I started using this plug-in. I belive it crashed with something else on my system, at least it never worked as it should (maybe because of the VM setup?). But if you could send by another interface that sounds brilliant!

Just hang on, I have a new version to test in a few minutes. It has a new action, SendRESTcommand, and it works in the same way as the SendCommand but it uses the REST interface. It seems to work fine here. The good part is that the TCP port will only be used for EG listening to events and the REST when EG want's to send events. Should take care of eventual collisions or other disturbances that might happen on the TCP port...

Very inteRESTing, thanks!

There is a new one uploaded in the normal place

I have just to verify also changed my actions to use the new REST based ones and it is working perfect. Unfortunately you have to replace your existing ones with new types as well, hopefully not too many to add
Let's see if this kills ONH in your setup or if it survives

You are a funny guy!

Regular comedian I am! Thanks! I will implement this tomorrow for test, since I don't dare to mess with the system when the buyer's home.

OK, slightly confused... I replaced the plug-in and made an example send, which came out like this:
I could see that it sendt because the RFX logger showed the button in use. And that's the same code as I have had before. Do you mean that I need to change something in ONH itself?

The actual code I use to send off to an oven (with variables) is this:

Well, that's not correct, when you are sending like that you use the "old" standard and the TCP port

The new action looks like this example (copy as python)
The '77' is the id of the item in ONH

So for all your commands, you need to adopt the new format

Easiest to get the new format I think is to create a new SendRESTcommand for each, then copy as python to get the correct syntax

For your example, I think something like this:
where XY is the id in ONH of the device

Oh yes, and in ONH you should not need to change anything

Ah, I was writing while you were posting the second message. And the third message... I was thinking something like this:
Does that look correct? The problem is that the whole system builds on room numbers, so I can't have a separate on and off for each of the commands, I need to use a synax like the one I already have, or it's hours and hours of work again...

No it does not, how I built the new action we are depending on the id of the device from ONH (this is required when using the REST interface) But I also understand that you do not have the id available from your script. And since it is dynamic with room numbers, we can't just hard code it for each command.

One question: Are possible device names that you set with "Ovn "+str(Rom) defined as devices in ONH? If so, I will try to rewrite the action so that you can keep your old syntax like I will make a plugin internal lookup table device name <-> device id

Yeah, there is a system. All the ovens are Ovn 1 to Ovn 20, and the amps are Lydsone 1 to Lydsone 20. But do you mean the ID's that show in the XML for ONH? because I thought they changed from time to time. Maybe they don't do that?

What ever, if they would change, I will make a solution that keeps itself updated, it will anyway be invisible to the end user

Great! Oh, you are in no hurry, I'm pretty sure the buyer is home now, so I wont mess with anything more until Monday. I'll just let it flow without the offenting sends.