Sony Devices Binding

Tags: #<Tag:0x00007f1e53264b70>
(Knut) #644

Same thing here. Today I tried the WOL with SimpleIP. The magic packet was send but the tv didnt turn on:

2019-03-14 20:04:13.307 [DEBUG] [y.internal.simpleip.SimpleIpProtocol] - Sending WOL packet to FC:F1:52:A5:02:57 (
2019-03-14 20:04:13.308 [DEBUG] [y.internal.simpleip.SimpleIpProtocol] - Sending '*SCPOWR0000000000000001'
2019-03-14 20:04:14.072 [DEBUG] [] - Connecting to
2019-03-14 20:04:26.316 [DEBUG] [] - Connecting to
2019-03-14 20:04:38.320 [DEBUG] [] - Connecting to
2019-03-14 20:04:50.322 [DEBUG] [] - Connecting to
2019-03-14 20:05:02.325 [DEBUG] [] - Connecting to

Then it used my item defined with the WoL bindung and it turned on directly:

2019-03-14 20:07:20.828 [INFO ] [nhab.binding.wol.internal.WolBinding] - Wake-on-LAN packet sent [broadcastIp=, macaddress=fcf152a50257]
2019-03-14 20:07:21.470 [DEBUG] [] - Connecting to
2019-03-14 20:07:33.472 [DEBUG] [] - Connecting to
2019-03-14 20:07:45.476 [DEBUG] [] - Connecting to
2019-03-14 20:07:57.478 [DEBUG] [] - Connecting to
2019-03-14 20:08:08.424 [DEBUG] [larweb.ScalarWebDiscoveryParticipant] - Found Sony WebScalarAPI service: uuid:00000000-0000-1010-8000-fcf152a50257

Not a big thing. Using nhab.binding.wol.internal.WolBinding works good for me with some rules but if not needed it would be nice.


(Tim Roberts) #645

I think I spotted an error you two might be triggering - wait for the next version. I’m going to be gone for the next 5 days - so I’ll catch up when I get back…


(Knut) #646

I think chopping of last octet an replacing it with 255 will work in 99,9%. So i think this is totally fine.

Anyway an idea for some later optimization:
Maybe you can get a value from
The primary subnet of openhab can be defined there via Paper UI > Configuration > System Network Settings. With the IP and subnet mask the broadcast address can be calculated (sure you know this). On the downside i think its not required to set this so most users would not have done it. On the other hand its a dropdown value so maybe the information is there anyway.


(Knut) #647

With the new Version my Scalar thing is still not going online. Not much i can say about that at this moment so just a big log again. (14MB ziped to som KB). Zip-files are not allowed so after download rename it(delete “.log”).
SCALAR.7z.log (247.8 KB)


(AlexKid) #648

Ok it works only when I just turned off the TV. Otherwise after some time it doesn’t work “no route to Host”. Another problem is that the binding will forget the Mac adress and refresh value after some time. So I have created the TV within a. things file.


(Knut) #649

I cant see the “no route to host” error in my logs but it did not work for me too. To test it you have to turn off your tv for more than 5 minutes. You will see the binding is no longer online after that time. I even can hear my tv make a click sound. I think we wait to the next version.

In the meantime i use the integrated WoL Binding “WOL (Wake-on-LAN) Binding” (binding-wol1 - 1.13.0)

I defined an item like this:

Switch WoL_WZ_TV   "TV WoL"  <screen>  { wol="", autoupdate="false" }

I used autoupdate="false" because sending the WoL packet dosent mean the tv is really turned on. Maybe its unplugged or something. So after sending ON command to the item, wich triggers sending the WoL packet, it stays OFF.
To sync it with the real state of the tv read from the binding it use this simple rule:

rule "WoL_WZ_TV aktualisieren auf SonySimpleIP_Power.state"
	Item SonySimpleIP_Power changed 
	logInfo( "tv_wol.rules", "Rule 'WoL_WZ_TV aktualisieren auf SonySimpleIP_Power.state' triggered" )

This updates my WoL item when the tv is going ON or OFF even for instance if the tv remote is used.
Another rule helps me to send an OFF via the binding when i switch of my WoL item:

rule "WoL_WZ_TV zum Ausschalten nutzen"
	Item WoL_WZ_TV received command OFF  
	logInfo( "tv_wol.rules", "Rule 'WoL_WZ_TV zum Ausschalten nutzen' triggered" )

Works good.


(Andi) #650

Hi, thanks for the new binding. SimpleIP is working just fine. But i got problems with Scalar.
I got it registered with the 4-digit code, but since then it does not connect properly.
Can somebody support?

Attached i have a debug log (some seconds in normal logging, then switched to debug logging at some point)

sony_log.txt (556.2 KB)


(Tim Roberts) #651


Are you still around? I’m integrating your sonyaudio into the main sony one (working great so far and it covers SOOO many more devices as well - and it’s exposing some issues I had in mine with version handling!!).

I have a quick(?) question for you…

When you receive the notification - is the version on the notification always “1.0” (seems like it is). Example: if I call setPowerStatus using v1.1 style - the notification I get back is still 1.1 style but the notification itself says 1.0 style. Here’s a bit of the log - you can see my transport calling it with the v1.1 style and both your binding/mine receiving back a 1.0 notification even though it’s a 1.1 style:

2019-03-21 14:41:16.769 [DEBUG] [s.i.s.t.SonyWebSocketTransport:174  ] - Sending {"id":16,"method":"setPowerStatus","version":"1.1","params":[{"status":"off"}]} to ws://
2019-03-21 14:41:16.775 [DEBUG] [b.s.i.s.models.ScalarWebResult:94   ] - >>> result: 16, [], []
2019-03-21 14:41:16.775 [DEBUG] [s.i.s.t.SonyWebSocketTransport:201  ] - Response received from server: {"id":16,"result":[]}
2019-03-21 14:41:18.433 [DEBUG] [s.i.s.t.SonyWebSocketTransport:210  ] - Event received from server: {"method":"notifyPowerStatus","params":[{"standbyDetail":"","status":"standby"}],"version":"1.0"}
2019-03-21 14:41:18.431 [DEBUG] [.b.s.i.p.SonyAudioClientSocket:149  ] - Message received from server: {"method":"notifyPowerStatus","params":[{"standbyDetail":"","status":"standby"}],"version":"1.0"}
2019-03-21 14:41:18.432 [DEBUG] [.b.s.i.p.SonyAudioClientSocket:160  ] - Event received from server: {"method":"notifyPowerStatus","params":[{"standbyDetail":"","status":"standby"}],"version":"1.0"}

for now - I’m just assuming the notify format is the same version style as the originating calling version (so if I’m calling setPowerStatus 1.1 - the notification will be a 1.1 style).

Note: the above is on my HT-NT5 for reference…


(Tim Roberts) #652


The problem you are having is that the device is turned off when you started openHAB and it can’t get information from the TV when it’s off. That’s what I’m trying to solve with creating the device definitions but am not there yet.

For now - turn on the TV, start openHAB and it should come online - once it’s online , you can turn the TV on/off whatever and it should remain online. Just needs to be on when the binding is first starting up

As I said - this should be a bit temporary until I’ve got the definition thing the way I want it…


(Tim Roberts) #653

Just to let everyone know - the next update is pretty darn big. I’m integrating the sonyaudio stuff (websocket connections) and I’ve learned ALOT about the sony api and what I may have been doing wrong with it (mainly with the various API versions). However - it’s taking me awhile to get through everything - expect an update maybe next week (or the next).

Note: the update will hopefully fix the WOL thing as well…


(Andi) #654

Thanks for your reply. Unfortunately not working.
I turned on the TV and restarted OH2 completely, but still the same issue.
I unregistered OH as remote control restartet everything and reconnected and now the same issue.

Here from my logs (not in debug):

2019-03-22 08:39:08.439 [hingStatusInfoChangedEvent] - 'sony:scalar:mysonytv' changed from OFFLINE (COMMUNICATION_ERROR): Access Code requested. Please update the Access Code with what is shown on the device screen to OFFLINE (COMMUNICATION_ERROR): Storage doesn't exist.
2019-03-22 08:39:09.574 [me.event.ThingUpdatedEvent] - Thing 'sony:scalar:mysonytv' has been updated.
2019-03-22 08:39:09.578 [hingStatusInfoChangedEvent] - 'sony:scalar:mysonytv' changed from OFFLINE (COMMUNICATION_ERROR): Storage doesn't exist. to ONLINE
2019-03-22 08:39:25.845 [hingStatusInfoChangedEvent] - 'sony:scalar:mysonytv' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Storage doesn't exist.
2019-03-22 08:39:26.866 [me.event.ThingUpdatedEvent] - Thing 'sony:scalar:mysonytv' has been updated.

Ok the issue might be somewhere else. I completely removed the scalar thing, but these log are still coming regularly.

2019-03-22 08:43:46.092 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ScalarWebHandler tried updating the thing status although the handler was already disposed.
2019-03-22 08:43:47.182 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler ScalarWebHandler tried updating thing sony:scalar:mysonytv although the handler was already disposed.

After a restart the thing seems to be really gone, but after adding the thing again, to problem reoccours just like before :frowning:


(Tim Roberts) #655

Thanks - I’ll need to look harder into that error then - something is leaking out to the thing and pulling it off line. I’ll see what I can do. As for the messages occurring - that’s something I have fixed in my version that you’ll get in the next (wasn’t properly cleaning up a thread)

1 Like

(Tim Roberts) #656

Just a quick update - still working on the code. I’ve had to do some extensive reworks based on some (wrong) assumptions I made with the prior code and I’m still testing through those changes. On the plus side, the binding now works with my soundbar and has enabled scalar on my bluray players. I’ve also ordered a AVR (dn1080) to test with (suppose to arrive next week - may or may not be able to test with it before the next release). I think a version might be good to release next week.

Please note that there will be some backward compatibility issues with this (I’m dropping one channel) and I definitely will have some files for you all to send me back.

Stay tuned…



(Tim Roberts) #657

I’m having troubles finding that “storage doesn’t exist” issue. Could you stop your openhab, blow the log away, and restart openhab - wait until it goes offline again with “storage doesn’t exist” - then send me the log? I need to see all the steps it’s taking to get there.

Note: instead of posting to the log - could you just put it into and post the link. That way it’s not taking up resources…



(Andi) #658

Hi Tim,

of course, i am happy to help. Here you go:

For a short time the thing goes online (which can also be seen in the log) and then i am able to control the TV, but shortly after that it goes offline

Storage doesn't exist.

If you got questions feel free to ask :slight_smile:


(Tim Roberts) #659


Are you running this on a PI by any chance? It looks like the connection attempt is running longer than it should and is being cancelled each time (which may be a result of an slow processor like the PI). Regardless - could you go into the thing configuration and bump the “Retry Polling” setting up (make it like 60) and see if it goes online.



(Andi) #660

Yes i am running it on an RPi 3. I guess recources shouldn’t be an issue since there is plenty of CPU and memory recources left. Changing the polling to 60s made that the thing stayed online for approx. 60s and then went offline with the same error. Maybe i should just deactivate the polling :smiley:

Edit: When deactivating the polling (-1s) it actually seems that the Thing stays online and operable. However i don’t know what could be the negative long term effects.

Furthermore i noticed the (new) behaviour that the tv channel switches remain ON when i switch to a new channel. In the old binding version i can remeber that it was different. I am not sure if a switch immediately went OFF again or if only the last switch remained ON and the others turned OFF. This way several (in an extreme case all) channels could be ON at the same time. Don’t know if this is intended, so thought i report :slight_smile:


(Tim Roberts) #661

From working with the NEEO binding - I know PIs have limited capabilities and the sony addon will definitely stress it out at startup because it does a BUNCH of calls/processing to startup (and on each polling). With polling disabled, you’re seeing some of the side effects - if there is a channel that affects other channels, those other channels won’t change because the polling is disabled (so the other channels won’t turn to OFF because it doesn’t know it’s off). Outside of what you noticed, there will be side effects to volume and a few other things that are ‘related’.

Just an experiment - Try setting it to some huge value (like 600 for 10 minutes) and see if it comes online (stays online) and your ON/OFF goes away (of course after 10 minutes). I’m betting it will. If it doesn’t - it’s something in my code.

Performance will eventually be looked at (like I did with NEEO addon and got it to run reasonably on a PI3) - but it’s not very high on the priority right now unfortunately…

Another interesting thing - you can keep it at -1, look in your log for “Attempting connection to Scalar Web device…” and note the timestamp. Then look after that to the “ONLINE” debug message to see it’s timestamp - that should tell you how long it took to do the initial (and polling) time. Would be interesting to hear what it was (then you can intelligently set the polling to that time plus some extra)


(Andi) #662

Thanks for your suggestions. Here is what i found out:

I set the “retry polling” to 600s. During the first 10 minutes i can change channels and the ON/OFF switches issue is not present like when I set i to -1s. When activating a new channel the previous goes off. But after 10 minutes the Thing goes off again:

2019-04-04 17:25:07.888 [hingStatusInfoChangedEvent] - 'sony:scalar:18e7d15c5870' changed from OFFLINE (COMMUNICATION_ERROR): Storage doesn't exist. to ONLINE
2019-04-04 17:35:18.543 [hingStatusInfoChangedEvent] - 'sony:scalar:18e7d15c5870' changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Storage doesn't exist.

What i also found out is that my Thing changes over time (i suspect when the port changes in the Scalar Web URL). When it changes all settings are reset. So my access code is “RQST” again and my retry polling is also the default value again. Observed that behaviour several times now. Don’t know if it is related, but it seems this is (also) a bug.


(Tim Roberts) #663

Interesting about the port change - if that’s the case, I see why all the values change back as well (since that’s part of discovery). Let me think on that one

1 Like