digitaldan/jomnilink

Java library for the HAI OmniLink II protocol

jomnilink's Issues

Unsafe cast in notification listener dispatch.

This code does not do a proper check before casting:

if (message instanceof ObjectStatus) {
  listener.objectStatusNotification((ObjectStatus) message);
} else {
  listener.otherEventNotification((OtherEventNotifications) message);
}	

This is causing issues in the openhab binding:

2017-07-05 20:28:11.709 [ERROR] [om.digitaldan.jomnilinkII.Connection] - Notifcation Handler Caught Exception
java.lang.ClassCastException: com.digitaldan.jomnilinkII.MessageTypes.AudioSourceStatus cannot be cast to com.digitaldan.jomnilinkII.MessageTypes.OtherEventNotifications
        at com.digitaldan.jomnilinkII.Connection$NotificationHandler.run(Connection.java:844)[263:org.openhab.binding.omnilink:2.2.0.201707050940]
        at java.lang.Thread.run(Thread.java:748)[:1.8.0_131]

Migrate off Travis

@digitaldan Just an FYI but Travis CI is no longer free and once you run out of your allotment of free minutes, you will have to pay.

I would suggest migrating to GitHub Actions, there is a large amount of documentation available online at https://docs.github.com/en/actions.

Just a thought.

jomnilink extended status for units bug

Hi Dan,

Seeing as you are getting back into the omnilink world, I though we should look at what I think is a bug in the jomnilink.

We discussed back in late April:
https://community.openhab.org/t/jomnilink-question/27183/2

`Within connection.java, in the

public ObjectStatus reqObjectStatus(int objectType, int startObject, int endObject, boolean extended)
there is the following code:

if (extended) {
msg = sendAndReceive(new ReqObjectStatus(objectType, current, next));
} else {
msg = sendAndReceive(new ReqExtenedObjectStatus(objectType, current, next));
}`

I believe the statements in the if and else should be swapped.

Missing Console Beep Commands

@digitaldan -
I am not sure if you are following the openhab2 binding repo, so I am opening an issue here.
I think that the console beep elements you added were not pushed back into this library. This is making my build fail against your latest branch of the binding.
It was blocking my thermostat PR, but it looks like @craigham merged that PR anyway so I suspect that branch is now failing it's build.

Fix typo in NotificationListener

Do we want to fix the method type in NotificationListener:
public void objectStausNotification(ObjectStatus status)

Change to:
public void objectStatusNotification(ObjectStatus status)

If we do want to fix it, do we want to deprecate the old method for a while but have both fire?

Versioning and Releasing

@digitaldan -
Do we need to figure out how to automatically release and version this library? It would be nice to get this so its available in maven, etc (I guess through jfrog/bintray - but I have never done it). I now that @craigham setup auto builds / releases for the binding.. Maybe he can help us out?

I am bringing this up because I need to change the library to support changes to thermostats in for omnilink 3.x.

Temperatures return as int

Shouldn't temperatures be returned as a double or float rather than as an int @digitaldan?

Temperature in Deg C not displaying 0.5 deg increments.

Temperature output only displays the integer value. Any decimal value is not passed through resulting in a temperature which is reported as 26.5 dec C by the omni controller being displayed as 26.0 deg by the omnilink binding.

Thermostat fan and hold support is incomplete

Does support 'fan cycle' and 'vacation hold'.

Those elements need to move from a boolean to an int.

PR forthcoming.

Status classes are not immutable

This leads to difficult reasoning in multhreaded environments.

uploadNames and uploadLogEventData always throw an exception?

@digitaldan
I haven't run into an issue in practice and maybe I am just missing something here. But I think the logic is off on uploadNames and uploadLogEventData methods.
The code is here

public Message uploadEventLogData(int number, int direction) throws IOException, OmniNotConnectedException,
			OmniInvalidResponseException, OmniUnknownMessageTypeException {
		Message msg = sendAndReceive(new UploadEventRecord(number, direction));
		if (msg.getMessageType() != Message.MESG_TYPE_EVENT_LOG_DATA
				&& msg.getMessageType() != Message.MESG_TYPE_END_OF_DATA) {
			throw new OmniInvalidResponseException(msg);
		}
		return msg;
	}

Doesn't that check on message type need to be a logical or rather than a logical and? The returned method type is never going to be both types, so it would always throw an exception, right?

License?

@digitaldan -
Can we change the license away from GPL? With the current license I am not sure if this can ever be shipped with something like openhab? I don't know what license to suggest.. apache, eclipse?